there are two or three patches, extensions, features, or bugs being
discussed at a time.
-A searchable archive of the list is at:
+A searchable archive of the list is at either:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/
-The list is also archived under the usenet group name
-C<perl.porters-gw> at:
+or
- http://www.deja.com/
+ http://archive.develooper.com/perl5-porters@perl.org/
List subscribers (the porters themselves) come in several flavours.
Some are quiet curious lurkers, who rarely pitch in and instead watch
=over 4
-=item It's easier
+=item It's easier to rsync the source tree
Since you don't have to apply the patches yourself, you are sure all
files in the source tree are in the right state.
=over 4
-=item It's easier
+=item It's easier to rsync the patches
If you have more than one machine that you want to keep in track with
bleadperl, it's easier to rsync the patches only once and then apply
perl's bugtron to find more information about discussions and
ramblings on posted bugs.
-=back
-
If you want to get the best of both worlds, rsync both the source
tree for convenience, reliability and ease and rsync the patches
for reference.
+=back
+
+
+=head2 Perlbug remote interface
+
+=over 4
+
+There are three (3) remote administrative interfaces for modifying bug status, category, etc. In all cases an admin must be first registered with the Perlbug database by sending an email request to richard@perl.org or bugmongers@perl.org.
+
+The main requirement is the willingness to classify, (with the emphasis on closing where possible :), outstanding bugs. Further explanation can be garnered from the web at http://bugs.perl.org/, or by asking on the admin mailing list at: bugmongers@perl.org
+
+For more info on the web see
+
+ http://bugs.perl.org/perlbug.cgi?req=spec
+
+
+B<The interfaces:>
+
+
+=item 1 http://bugs.perl.org
+
+Login via the web, (remove B<admin/> if only browsing), where interested Cc's, tests, patches and change-ids, etc. may be assigned.
+
+ http://bugs.perl.org/admin/index.html
+
+
+=item 2 bugdb@perl.org
+
+Where the subject line is used for commands:
+
+ To: bugdb@perl.org
+ Subject: -a close bugid1 bugid2 aix install
+
+ To: bugdb@perl.org
+ Subject: -h
+
+
+=item 3 commands_and_bugdids@bugs.perl.org
+
+Where the address itself is the source for the commands:
+
+ To: close_bugid1_bugid2_aix@bugs.perl.org
+
+ To: help@bugs.perl.org
+
+
+=item notes, patches, tests
+
+For patches and tests, the message body is assigned to the appropriate bug/s and forwarded to p5p for their attention.
+
+ To: test_<bugid1>_aix_close@bugs.perl.org
+ Subject: this is a test for the (now closed) aix bug
+
+ Test is the body of the mail
+
+=back
+
=head2 Submitting patches
Always submit patches to I<perl5-porters@perl.org>. If you're
}
}
-< finish this later >
+# finish this later #
=head2 Patching
tests to make sure our patch works and doesn't create a bug somewhere
else along the line.
-The regression tests for each operator live in F<t/op/>, and so we make
-a copy of F<t/op/pack.t> to F<t/op/pack.t~>. Now we can add our tests
-to the end. First, we'll test that the C<U> does indeed create Unicode
-strings:
+The regression tests for each operator live in F<t/op/>, and so we
+make a copy of F<t/op/pack.t> to F<t/op/pack.t~>. Now we can add our
+tests to the end. First, we'll test that the C<U> does indeed create
+Unicode strings.
+
+t/op/pack.t has a sensible ok() function, but if it didn't we could
+use the one from t/test.pl.
+
+ require './test.pl';
+ plan( tests => 159 );
+
+so instead of this:
print 'not ' unless "1.20.300.4000" eq sprintf "%vd", pack("U*",1,20,300,4000);
print "ok $test\n"; $test++;
+we can write the more sensible (see L<Test::More> for a full
+explanation of is() and other testing functions).
+
+ is( "1.20.300.4000", sprintf "%vd", pack("U*",1,20,300,4000),
+ "U* produces unicode" );
+
Now we'll test that we got that space-at-the-beginning business right:
- print 'not ' unless "1.20.300.4000" eq
- sprintf "%vd", pack(" U*",1,20,300,4000);
- print "ok $test\n"; $test++;
+ is( "1.20.300.4000", sprintf "%vd", pack(" U*",1,20,300,4000),
+ " with spaces at the beginning" );
And finally we'll test that we don't make Unicode strings if C<U> is B<not>
the first active format:
- print 'not ' unless v1.20.300.4000 ne
- sprintf "%vd", pack("C0U*",1,20,300,4000);
- print "ok $test\n"; $test++;
+ isnt( v1.20.300.4000, sprintf "%vd", pack("C0U*",1,20,300,4000),
+ "U* not first isn't unicode" );
+
+Mustn't forget to change the number of tests which appears at the top,
+or else the automated tester will get confused. This will either look
+like this:
-Mustn't forget to change the number of tests which appears at the top, or
-else the automated tester will get confused:
+ print "1..156\n";
- -print "1..156\n";
- +print "1..159\n";
+or this:
+
+ plan( tests => 156 );
We now compile up Perl, and run it through the test suite. Our new
tests pass, hooray!
maintainer keep the CPAN version in sync with the core version without
constantly scanning p5p.
+=head2 Adding a new function to the core
+
+If, as part of a patch to fix a bug, or just because you have an
+especially good idea, you decide to add a new function to the core,
+discuss your ideas on p5p well before you start work. It may be that
+someone else has already attempted to do what you are considering and
+can give lots of good advice or even provide you with bits of code
+that they already started (but never finished).
+
+You have to follow all of the advice given above for patching. It is
+extremely important to test any addition thoroughly and add new tests
+to explore all boundary conditions that your new function is expected
+to handle. If your new function is used only by one module (e.g. toke),
+then it should probably be named S_your_function (for static); on the
+other hand, if you expect it to accessible from other functions in
+Perl, you should name it Perl_your_function. See L<perlguts/Internal Functions>
+for more details.
+
+The location of any new code is also an important consideration. Don't
+just create a new top level .c file and put your code there; you would
+have to make changes to Configure (so the Makefile is created properly),
+as well as possibly lots of include files. This is strictly pumpking
+business.
+
+It is better to add your function to one of the existing top level
+source code files, but your choice is complicated by the nature of
+the Perl distribution. Only the files that are marked as compiled
+static are located in the perl executable. Everything else is located
+in the shared library (or DLL if you are running under WIN32). So,
+for example, if a function was only used by functions located in
+toke.c, then your code can go in toke.c. If, however, you want to call
+the function from universal.c, then you should put your code in another
+location, for example util.c.
+
+In addition to writing your c-code, you will need to create an
+appropriate entry in embed.pl describing your function, then run
+'make regen_headers' to create the entries in the numerous header
+files that perl needs to compile correctly. See L<perlguts/Internal Functions>
+for information on the various options that you can set in embed.pl.
+You will forget to do this a few (or many) times and you will get
+warnings during the compilation phase. Make sure that you mention
+this when you post your patch to P5P; the pumpking needs to know this.
+
+When you write your new code, please be conscious of existing code
+conventions used in the perl source files. See <perlstyle> for
+details. Although most of the guidelines discussed seem to focus on
+Perl code, rather than c, they all apply (except when they don't ;).
+See also I<Porting/patching.pod> file in the Perl source distribution
+for lots of details about both formatting and submitting patches of
+your changes.
+
+Lastly, TEST TEST TEST TEST TEST any code before posting to p5p.
+Test on as many platforms as you can find. Test as many perl
+Configure options as you can (e.g. MULTIPLICITY). If you have
+profiling or memory tools, see L<EXTERNAL TOOLS FOR DEBUGGING PERL>
+below for how to use them to further test your code. Remember that
+most of the people on P5P are doing this on their own time and
+don't have the time to debug your code.
=head2 Writing a test
=item F<t/cmd/>
These test the basic control structures, C<if/else>, C<while>,
-subroutines, etc...
+subroutines, etc.
=item F<t/comp/>
"ok/not ok" run through Test::Harness, but there are a few special
considerations.
-For most libraries and extensions, you'll want to use the Test::More
-library rather than rolling your own test functions. If a module test
-doesn't use Test::More, consider rewriting it so it does. For the
-rest its best to use a simple C<print "ok $test_num\n"> style to avoid
-broken core functionality from causing the whole test to collapse.
+There are three ways to write a test in the core. Test::More,
+t/test.pl and ad hoc C<print $test ? "ok 42\n" : "not ok 42\n">. The
+decision of which to use depends on what part of the test suite you're
+working on. This is a measure to prevent a high-level failure (such
+as Config.pm breaking) from causing basic functionality tests to fail.
+
+=over 4
+
+=item t/base t/comp
+
+Since we don't know if require works, or even subroutines, use ad hoc
+tests for these two. Step carefully to avoid using the feature being
+tested.
+
+=item t/cmd t/run t/io t/op
+
+Now that basic require() and subroutines are tested, you can use the
+t/test.pl library which emulates the important features of Test::More
+while using a minimum of core features.
+
+You can also conditionally use certain libraries like Config, but be
+sure to skip the test gracefully if it's not there.
+
+=item t/lib ext lib
+
+Now that the core of Perl is tested, Test::More can be used. You can
+also use the full suite of core modules in the tests.
+
+=back
When you say "make test" Perl uses the F<t/TEST> program to run the
test suite. All tests are run from the F<t/> directory, B<not> the
Depending on your platform there are various of profiling Perl.
There are two commonly used techniques of profiling executables:
-E<statistical time-sampling> and E<basic-block counting>.
+I<statistical time-sampling> and I<basic-block counting>.
The first method takes periodically samples of the CPU program
counter, and since the program counter can be correlated with the code
good idea for profiling), the second problem is usually kept in guard
by the profiling tools themselves.
-The second method divides up the generated code into E<basic blocks>.
+The second method divides up the generated code into I<basic blocks>.
Basic blocks are sections of code that are entered only in the
beginning and exited only at the end. For example, a conditional jump
starts a basic block. Basic block profiling usually works by
-E<instrumenting> the code by adding E<enter basic block #nnnn>
+I<instrumenting> the code by adding I<enter basic block #nnnn>
book-keeping code to the generated code. During the execution of the
code the basic block counters are then updated appropriately. The
caveat is that the added extra code can skew the results: again, the
=head2 GCC gcov Profiling
-Starting from GCC 3.0 E<basic block profiling> is officially available
+Starting from GCC 3.0 I<basic block profiling> is officially available
for the GNU CC.
You can build a profiled version of perl called F<perl.gcov> by
Pixie is a profiling tool available on IRIX and Tru64 (aka Digital
UNIX aka DEC OSF/1) platforms. Pixie does its profiling using
-E<basic-block counting>.
+I<basic-block counting>.
You can build a profiled version of perl called F<perl.pixie> by
invoking the make target "perl.pixie" (what is required is that Perl
projects / p5sagit/p5-mst-13.2.git / blobdiff