releases of Perl are shepherded by a ``pumpking'', a porter
responsible for gathering patches, deciding on a patch-by-patch
feature-by-feature basis what will and will not go into the release.
-For instance, Gurusamy Sarathy is the pumpking for the 5.6 release of
-Perl.
+For instance, Gurusamy Sarathy was the pumpking for the 5.6 release of
+Perl, and Jarkko Hietaniemi is the pumpking for the 5.8 release, and
+Hugo van der Sanden will be the pumpking for the 5.10 release.
In addition, various people are pumpkings for different things. For
instance, Andy Dougherty and Jarkko Hietaniemi share the I<Configure>
-pumpkin, and Tom Christiansen is the documentation pumpking.
+pumpkin.
Larry sees Perl development along the lines of the US government:
there's the Legislature (the porters), the Executive branch (the
unlikely that nonportable additions to the Perl language will be
accepted.
+=item Is the implementation tested?
+
+Patches which change behaviour (fixing bugs or introducing new features)
+must include regression tests to verify that everything works as expected.
+Without tests provided by the original author, how can anyone else changing
+perl in the future be sure that they haven't unwittingly broken the behaviour
+the patch implements? And without tests, how can the patch's author be
+confident that his/her hard work put into the patch won't be accidentally
+thrown away by someone in the future?
+
=item Is there enough documentation?
Patches without documentation are probably ill-thought out or
incomplete. Nothing can be added without documentation, so submitting
a patch for the appropriate manpages as well as the source code is
-always a good idea. If appropriate, patches should add to the test
-suite as well.
+always a good idea.
=item Is there another way to do it?
It's then up to you to apply these patches, using something like
- # last=`ls -rt1 *.gz | tail -1`
+ # last=`ls -t *.gz | sed q`
# rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
# find . -name '*.gz' -newer $last -exec gzcat {} \; >blead.patch
# cd ../perl-current
to L<perlguts/Background and PERL_IMPLICIT_CONTEXT> for information on
the C<[pad]THX_?> macros.
-
=head2 Poking at Perl
To really poke around with Perl, you'll probably want to build Perl for
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 accessable from other functions in
+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.
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 futher test your code. Remember that
+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.
This binary is used in place of the standard 'perl' binary
when you want to debug Perl memory problems.
+To minimize the number of memory leak false alarms
+(see L</PERL_DESTRUCT_LEVEL>), set environment variable
+PERL_DESTRUCT_LEVEL to 2.
+
+ setenv PERL_DESTRUCT_LEVEL 2
+
+In Bourne-type shells:
+
+ PERL_DESTRUCT_LEVEL=2
+ export PERL_DESTRUCT_LEVEL
+
As an example, to show any memory leaks produced during the
standard Perl testset you would create and run the Purify'ed
perl as:
setenv PURIFYOPTIONS "-chain-length=25"
+In Bourne-type shells:
+
+ PURIFY_OPTIONS="..."
+ export PURIFY_OPTIONS
+
+or if you have the "env" utility:
+
+ env PURIFY_OPTIONS="..." ../pureperl ...
+
=head2 Purify on NT
Purify on Windows NT instruments the Perl binary 'perl.exe'
environment variable PERL_DESTRUCT_LEVEL to a non-zero value.
The t/TEST wrapper does set this to 2, and this is what you
need to do too, if you don't want to see the "global leaks":
+For example, for "third-degreed" Perl:
- PERL_DESTRUCT_LEVEL=2 ./perl.third t/foo/bar.t
+ env PERL_DESTRUCT_LEVEL=2 ./perl.third -Ilib t/foo/bar.t
=head2 Profiling
For further information, see your system's manual pages for pixie and prof.
+=head2 Miscellaneous tricks
+
+=over 4
+
+=item *
+
+Those debugging perl with the DDD frontend over gdb may find the
+following useful:
+
+You can extend the data conversion shortcuts menu, so for example you
+can display an SV's IV value with one click, without doing any typing.
+To do that simply edit ~/.ddd/init file and add after:
+
+ ! Display shortcuts.
+ Ddd*gdbDisplayShortcuts: \
+ /t () // Convert to Bin\n\
+ /d () // Convert to Dec\n\
+ /x () // Convert to Hex\n\
+ /o () // Convert to Oct(\n\
+
+the following two lines:
+
+ ((XPV*) (())->sv_any )->xpv_pv // 2pvx\n\
+ ((XPVIV*) (())->sv_any )->xiv_iv // 2ivx
+
+so now you can do ivx and pvx lookups or you can plug there the
+sv_peek "conversion":
+
+ Perl_sv_peek(my_perl, (SV*)()) // sv_peek
+
+(The my_perl is for threaded builds.)
+Just remember that every line, but the last one, should end with \n\
+
+Alternatively edit the init file interactively via:
+3rd mouse button -> New Display -> Edit Menu
+
+Note: you can define up to 20 conversion shortcuts in the gdb
+section.
+
+=back
+
=head2 CONCLUSION
We've had a brief look around the Perl source, an overview of the stages
projects / p5sagit/p5-mst-13.2.git / blobdiff