charnames.t: indent newly formed block

[perl5.git] / pod / perlhack.pod

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index 93021b2..831f407 100644 (file)
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -283,7 +283,7 @@ to B<maintenance>. (With an exception for some patches that document
 behaviour that only appears in the maintenance branch, but which has
 changed in the development version.)
 
-To report a bug in Perl, use the program I<perlbug> which comes with
+To report a bug in Perl, use the program L<perlbug> which comes with
 Perl (if you can't get Perl to work, send mail to the address
 I<perlbug@perl.org> or I<perlbug@perl.com>).  Reporting bugs through
 I<perlbug> feeds into the automated bug-tracking system, access to
@@ -384,6 +384,10 @@ core:
     dist/ is for dual-life modules, where the blead source is
           canonical.
 
+For some dual-life modules it has not been discussed if the CPAN version or the
+blead source is canonical. Until that is done, those modules should be in
+F<cpan/>.
+
 =item Tests
 
 There are tests for nearly all the modules, built-ins and major bits
@@ -553,7 +557,7 @@ that's left to do is run it. The actual execution is done by the
 C<runops_standard> function in F<run.c>; more specifically, it's done by
 these three innocent looking lines:
 
-    while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
+    while ((PL_op = PL_op->op_ppaddr(aTHX))) {
         PERL_ASYNC_CHECK();
     }
 
@@ -1758,6 +1762,10 @@ so there are some snags (and it would be wonderful for you to brush
 them out), but it basically works that way.  Everything else lives in
 F<t/>.
 
+Testing of warning messages is often separately done by using expect scripts in
+F<t/lib/warnings>.  This is because much of the setup for them is already done
+for you.
+
 If you add a new test directory under F<t/>, it is imperative that you 
 add that directory to F<t/HARNESS> and F<t/TEST>.
 
@@ -1832,6 +1840,7 @@ 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.
+If you write your own test, use the L<Test Anything Protocol|TAP>.
 
 =over 4
 
@@ -2990,7 +2999,7 @@ each SV allocation is also logged.
 
 =head2 Profiling
 
-Depending on your platform there are various of profiling Perl.
+Depending on your platform there are various ways of profiling Perl.
 
 There are two commonly used techniques of profiling executables:
 I<statistical time-sampling> and I<basic-block counting>.
@@ -3110,7 +3119,8 @@ and its section titled "8. gcov: a Test Coverage Program"
 
 quick hint:
 
-    $ sh Configure -des  -Doptimize='-g' -Accflags='-fprofile-arcs -ftest-coverage' \
+    $ sh Configure -des -Dusedevel -Doptimize='-g' \
+        -Accflags='-fprofile-arcs -ftest-coverage' \
         -Aldflags='-fprofile-arcs -ftest-coverage' && make perl.gcov
     $ rm -f regexec.c.gcov regexec.gcda
     $ ./perl.gcov