% git remote add fork git@github.com:MyUser/perl5.git
+For more information, see L<"Connecting to GitHub with SSH"|https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/connecting-to-github-with-ssh>.
+
+If you'd rather use an HTTPS URL for your C<git push> see L<"Cloning with
+HTTPS URLs"|https://docs.github.com/en/free-pro-team@latest/github/using-git/which-remote-url-should-i-use#cloning-with-https-urls>.
+
+ % git remote add fork https://github.com/MyUser/perl5.git
+
Then, push your new branch to your fork.
% git push -u fork mychange
Good patches (tight code, complete, correct) stand more chance of going
in. Sloppy or incorrect patches might be placed on the back burner
-until the pumpking has time to fix, or might be discarded altogether
+until fixes can be made, or they might be discarded altogether
without further notice.
=head3 Is the implementation generic enough to be portable?
=head3 Does it create too much work?
-Work for the pumpking, work for Perl programmers, work for module
+Work for the committers, work for Perl programmers, work for module
authors, ... Perl is supposed to be easy.
=head3 Patches speak louder than words
rather than in F<t/op> because they test functionality which
F<t/test.pl> presumes has already been demonstrated to work.
-=item * F<t/cmd>, F<t/run>, F<t/io> and F<t/op>
+=item * All other subdirectories of F<t/>
Now that basic require() and subroutines are tested, you can use the
F<t/test.pl> library.
-You can also use certain libraries like Config conditionally, but be
+You can also use certain libraries like L<Config> conditionally, but be
sure to skip the test gracefully if it's not there.
-=item * Everything else
+=item * Test files not found under F<t/>
-Now that the core of Perl is tested, L<Test::More> can and should be
-used. You can also use the full suite of core modules in the tests.
+This category includes F<.t> files underneath directories such as F<dist>,
+F<ext> and F<lib>. Since the core of Perl has now been tested, L<Test::More>
+can and now should be used. You can also use the full suite of core modules
+in the tests. (As noted in L<"Patching a core module"> above, changes to
+F<.t> files found under F<cpan/> should be submitted to the upstream
+maintainers of those modules.)
=back
C<"\x80\x41"> on an EBCDIC 1047 one.
But easiest is, if the character is specifiable as a literal, like
-C<"A"> or C<"%">, to use that; if not so specificable, you can use use
+C<"A"> or C<"%">, to use that; if not so specificable, you can use
C<\N{}> , if the side effects aren't troublesome. Simply specify all
your characters in hex, using C<\N{U+ZZ}> instead of C<\xZZ>. C<\N{}>
is the Unicode name, and so it
Run F<miniperl> on F<t/base>, F<t/comp>, F<t/cmd>, F<t/run>, F<t/io>,
F<t/op>, F<t/uni> and F<t/mro> tests.
+F<miniperl> is a minimalistic perl built to bootstrap building
+extensions, utilties, documentation etc. It doesn't support dynamic
+loading and depending on the point in the build process will only have
+access to a limited set of core modules. F<miniperl> is not intended
+for day to day use.
+
=item * test.valgrind check.valgrind
(Only in Linux) Run all the tests using the memory leak + naughty
=head2 Parallel tests
The core distribution can now run its regression tests in parallel on
-Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS>
-in your environment to the number of tests to run in parallel, and run
-C<make test_harness>. On a Bourne-like shell, this can be done as
+Unix-like and Windows platforms. On Unix, instead of running C<make
+test>, set C<TEST_JOBS> in your environment to the number of tests to
+run in parallel, and run C<make test_harness>. On a Bourne-like shell,
+this can be done as
TEST_JOBS=3 make test_harness # Run 3 tests in parallel
non-conflicting test scripts itself, and there is no standard interface
to C<make> utilities to interact with their job schedulers.
-Note that currently some test scripts may fail when run in parallel
-(most notably F<dist/IO/t/io_dir.t>). If necessary, run just the
-failing scripts again sequentially and see if the failures go away.
+Tests are normally run in a logical order, with the sanity tests first,
+then the main tests of the Perl core functionality, then the tests for
+the non-core modules. On many-core systems, this may not use the
+hardware as effectively as possible. By also specifying
+
+ TEST_JOBS=19 PERL_TEST_HARNESS_ASAP=1 make -j19 test_harness
+
+you signal that you want the tests to finish in wall-clock time as short
+as possible. After the sanity tests are completed, this causes the
+remaining ones to be packed into the available cores as tightly as
+we know how. This has its greatest effect on slower, many-core systems.
+Throughput was sped up by 20% on an outmoded 24-core system; less on
+more recent faster ones with fewer cores.
+
+Note that the command line above added a C<-j> parameter to make, so as
+to cause parallel compilation. This may or may not work on your
+platform.
=head2 Running tests by hand
mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o \
pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o \
utf8.o taint.o deb.o universal.o globals.o perlio.o \
- perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o \
+ numeric.o mathoms.o locale.o pp_pack.o pp_sort.o \
miniperlmain.o opmini.o perlmini.o
pp.o: In function `Perl_pp_pow':
pp.c:(.text+0x2db9): undefined reference to `pow'
Gisle Aas's "illustrated perlguts", also known as I<illguts>, has very
helpful pictures:
-L<https://search.cpan.org/dist/illguts/>
+L<https://metacpan.org/release/RURBAN/illguts-0.49>
=item * L<perlxstut> and L<perlxs>
=item * F<Porting/pumpkin.pod>
This is a collection of words of wisdom for a Perl porter; some of it
-is only useful to the pumpkin holder, but most of it applies to anyone
+is only useful to the pumpkin holders, but most of it applies to anyone
wanting to go about Perl development.
=back
Both efforts welcome volunteers. In order to get involved in smoke
testing of the perl itself visit
-L<https://search.cpan.org/dist/Test-Smoke/>. In order to start smoke
+L<https://metacpan.org/release/Test-Smoke>. In order to start smoke
testing CPAN modules visit
-L<https://search.cpan.org/dist/CPANPLUS-YACSmoke/> or
-L<https://search.cpan.org/dist/minismokebox/> or
-L<https://search.cpan.org/dist/CPAN-Reporter/>.
+L<https://metacpan.org/release/CPANPLUS-YACSmoke> or
+L<https://metacpan.org/release/minismokebox> or
+L<https://metacpan.org/release/CPAN-Reporter>.
=head1 WHAT NEXT?
https://perl5.git.perl.org / perl5.git / blobdiff