perlhack.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

ramblings on posted bugs.
.Sp
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.
.RE
.Sh "Working with the source"
.IX Subsection "Working with the source"
Because you cannot use the Perforce client, you cannot easily generate
diffs against the repository, nor will merges occur when you update
via rsync.  If you edit a file locally and then rsync against the
latest source, changes made in the remote copy will \fIoverwrite\fR your
local versions!
.PP
The best way to deal with this is to maintain a tree of symlinks to
the rsync'd source.  Then, when you want to edit a file, you remove
the symlink, copy the real file into the other tree, and edit it.  You
can then diff your edited file against the original to generate a
patch, and you can safely update the original tree.
.PP
Perl's \fIConfigure\fR script can generate this tree of symlinks for you.
The following example assumes that you have used rsync to pull a copy
of the Perl source into the \fIperl-rsync\fR directory.  In the directory
above that one, you can execute the following commands:
.PP
.Vb 3
\&  mkdir perl\-dev
\&  cd perl\-dev
\&  ../perl\-rsync/Configure \-Dmksymlinks \-Dusedevel \-D"optimize=\-g"
.Ve
.PP
This will start the Perl configuration process.  After a few prompts,
you should see something like this:
.PP
.Vb 1
\&  Symbolic links are supported.
\&
\&  Checking how to test for symbolic links...
\&  Your builtin \*(Aqtest \-h\*(Aq may be broken.
\&  Trying external \*(Aq/usr/bin/test \-h\*(Aq.
\&  You can test for symbolic links with \*(Aq/usr/bin/test \-h\*(Aq.
\&
\&  Creating the symbolic links...
\&  (First creating the subdirectories...)
\&  (Then creating the symlinks...)
.Ve
.PP
The specifics may vary based on your operating system, of course.
After you see this, you can abort the \fIConfigure\fR script, and you
will see that the directory you are in has a tree of symlinks to the
\&\fIperl-rsync\fR directories and files.
.PP
If you plan to do a lot of work with the Perl source, here are some
Bourne shell script functions that can make your life easier:
.PP
.Vb 9
\&    function edit {
\&        if [ \-L $1 ]; then
\&            mv $1 $1.orig
\&            cp $1.orig $1
\&            vi $1
\&        else
\&            vi $1
\&        fi
\&    }
\&
\&    function unedit {
\&        if [ \-L $1.orig ]; then
\&            rm $1
\&            mv $1.orig $1
\&        fi
\&    }
.Ve
.PP
Replace \*(L"vi\*(R" with your favorite flavor of editor.
.PP
Here is another function which will quickly generate a patch for the
files which have been edited in your symlink tree:
.PP
.Vb 12
\&    mkpatchorig() {
\&        local diffopts
\&        for f in \`find . \-name \*(Aq*.orig\*(Aq | sed s,^\e./,,\`
\&        do
\&            case \`echo $f | sed \*(Aqs,.orig$,,;s,.*\e.,,\*(Aq\` in
\&                c)   diffopts=\-p ;;
\&                pod) diffopts=\*(Aq\-F^=\*(Aq ;;
\&                *)   diffopts= ;;
\&            esac
\&            diff \-du $diffopts $f \`echo $f | sed \*(Aqs,.orig$,,\*(Aq\`
\&        done
\&    }
.Ve
.PP
This function produces patches which include enough context to make
your changes obvious.  This makes it easier for the Perl pumpking(s)
to review them when you send them to the perl5\-porters list, and that
means they're more likely to get applied.
.PP
This function assumed a \s-1GNU\s0 diff, and may require some tweaking for
other diff variants.
.Sh "Perlbug administration"
.IX Subsection "Perlbug administration"
There is a single remote administrative interface for modifying bug status,
category, open issues etc. using the \fB\s-1RT\s0\fR bugtracker system, maintained
by Robert Spier.  Become an administrator, and close any bugs you can get
your sticky mitts on:
.PP
.Vb 1
\&        http://bugs.perl.org/
.Ve
.PP
To email the bug system administrators:
.PP
.Vb 1
\&        "perlbug\-admin" <perlbug\[e-mail]>
.Ve
.Sh "Submitting patches"
.IX Subsection "Submitting patches"
Always submit patches to \fIperl5\[e-mail]\fR.  If you're
patching a core module and there's an author listed, send the author a
copy (see \*(L"Patching a core module\*(R").  This lets other porters review
your patch, which catches a surprising number of errors in patches.
Either use the diff program (available in source code form from
ftp://ftp.gnu.org/pub/gnu/ , or use Johan Vromans' \fImakepatch\fR
(available from \fICPAN/authors/id/JV/\fR).  Unified diffs are preferred,
but context diffs are accepted.  Do not send RCS-style diffs or diffs
without context lines.  More information is given in the
\&\fIPorting/patching.pod\fR file in the Perl source distribution.  Please
patch against the latest \fBdevelopment\fR version. (e.g., even if you're
fixing a bug in the 5.8 track, patch against the latest \fBdevelopment\fR
version rsynced from rsync://public.activestate.com/perl\-current/ )
.PP
If changes are accepted, they are applied to the development branch. Then
the 5.8 pumpking decides which of those patches is to be backported to the
maint branch.  Only patches that survive the heat of the development
branch get applied to maintenance versions.
.PP
Your patch should update the documentation and test suite.  See
\&\*(L"Writing a test\*(R".  If you have added or removed files in the distribution,
edit the \s-1MANIFEST\s0 file accordingly, sort the \s-1MANIFEST\s0 file using
\&\f(CW\*(C`make manisort\*(C'\fR, and include those changes as part of your patch.
.PP
Patching documentation also follows the same order: if accepted, a patch
is first applied to \fBdevelopment\fR, and if relevant then it's backported
to \fBmaintenance\fR. (With an exception for some patches that document
behaviour that only appears in the maintenance branch, but which has
changed in the development version.)
.PP
To report a bug in Perl, use the program \fIperlbug\fR which comes with
Perl (if you can't get Perl to work, send mail to the address
\&\[e-mail]\fR or \[e-mail]\fR).  Reporting bugs through
\&\fIperlbug\fR feeds into the automated bug-tracking system, access to
which is provided through the web at http://rt.perl.org/rt3/ .  It
often pays to check the archives of the perl5\-porters mailing list to
see whether the bug you're reporting has been reported before, and if
so whether it was considered a bug.  See above for the location of
the searchable archives.
.PP
The \s-1CPAN\s0 testers ( http://testers.cpan.org/ ) are a group of
volunteers who test \s-1CPAN\s0 modules on a variety of platforms.  Perl
Smokers ( http://www.nntp.perl.org/group/perl.daily\-build and
http://www.nntp.perl.org/group/perl.daily\-build.reports/ )
automatically test Perl source releases on platforms with various
configurations.  Both efforts welcome volunteers. In order to get
involved in smoke testing of the perl itself visit
<http://search.cpan.org/dist/Test\-Smoke>. In order to start smoke
testing \s-1CPAN\s0 modules visit <http://search.cpan.org/dist/CPAN\-YACSmoke/>
or <http://search.cpan.org/dist/POE\-Component\-CPAN\-YACSmoke/> or
<http://search.cpan.org/dist/CPAN\-Reporter/>.
.PP
It's a good idea to read and lurk for a while before chipping in.
That way you'll get to see the dynamic of the conversations, learn the
personalities of the players, and hopefully be better prepared to make
a useful contribution when do you speak up.
.PP
If after all this you still think you want to join the perl5\-porters
mailing list, send mail to \fIperl5\-porters\[e-mail]\fR.  To
unsubscribe, send mail to \fIperl5\-porters\[e-mail]\fR.
.PP
To hack on the Perl guts, you'll need to read the following things:
.IP "perlguts" 3
.IX Item "perlguts"
This is of paramount importance, since it's the documentation of what
goes where in the Perl source. Read it over a couple of times and it
might start to make sense \- don't worry if it doesn't yet, because the
best way to study it is to read it in conjunction with poking at Perl
source, and we'll do that later on.
.Sp
You might also want to look at Gisle Aas's illustrated perlguts \-
there's no guarantee that this will be absolutely up-to-date with the
latest documentation in the Perl core, but the fundamentals will be
right. ( http://gisle.aas.no/perl/illguts/ )
.IP "perlxstut and perlxs" 3
.IX Item "perlxstut and perlxs"
A working knowledge of \s-1XSUB\s0 programming is incredibly useful for core
hacking; XSUBs use techniques drawn from the \s-1PP\s0 code, the portion of the
guts that actually executes a Perl program. It's a lot gentler to learn
those techniques from simple examples and explanation than from the core
itself.
.IP "perlapi" 3
.IX Item "perlapi"
The documentation for the Perl \s-1API\s0 explains what some of the internal
functions do, as well as the many macros used in the source.
.IP "\fIPorting/pumpkin.pod\fR" 3
.IX Item "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
wanting to go about Perl development.
.IP "The perl5\-porters \s-1FAQ\s0" 3
.IX Item "The perl5-porters FAQ"
This should be available from http://dev.perl.org/perl5/docs/p5p\-faq.html .
It contains hints on reading perl5\-porters, information on how
perl5\-porters works and how Perl development in general works.
.Sh "Finding Your Way Around"
.IX Subsection "Finding Your Way Around"
Perl maintenance can be split into a number of areas, and certain people
(pumpkins) will have responsibility for each area. These areas sometimes
correspond to files or directories in the source kit. Among the areas are:
.IP "Core modules" 3
.IX Item "Core modules"
Modules shipped as part of the Perl core live in the \fIlib/\fR and \fIext/\fR
subdirectories: \fIlib/\fR is for the pure-Perl modules, and \fIext/\fR
contains the core \s-1XS\s0 modules.
.IP "Tests" 3
.IX Item "Tests"
There are tests for nearly all the modules, built-ins and major bits
of functionality.  Test files all have a .t suffix.  Module tests live
in the \fIlib/\fR and \fIext/\fR directories next to the module being
tested.  Others live in \fIt/\fR.  See \*(L"Writing a test\*(R"
.IP "Documentation" 3
.IX Item "Documentation"
Documentation maintenance includes looking after everything in the
\&\fIpod/\fR directory, (as well as contributing new documentation) and
the documentation to the modules in core.
.IP "Configure" 3
.IX Item "Configure"
The configure process is the way we make Perl portable across the
myriad of operating systems it supports. Responsibility for the
configure, build and installation process, as well as the overall
portability of the core code rests with the configure pumpkin \- others
help out with individual operating systems.
.Sp
The files involved are the operating system directories, (\fIwin32/\fR,
\&\fIos2/\fR, \fIvms/\fR and so on) the shell scripts which generate \fIconfig.h\fR
and \fIMakefile\fR, as well as the metaconfig files which generate
\&\fIConfigure\fR. (metaconfig isn't included in the core distribution.)
.IP "Interpreter" 3
.IX Item "Interpreter"
And of course, there's the core of the Perl interpreter itself. Let's
have a look at that in a little more detail.
.PP
Before we leave looking at the layout, though, don't forget that
\&\fI\s-1MANIFEST\s0\fR contains not only the file names in the Perl distribution,
but short descriptions of what's in them, too. For an overview of the
important files, try this:
.PP
.Vb 1
\&    perl \-lne \*(Aqprint if /^[^\e/]+\e.[ch]\es+/\*(Aq MANIFEST
.Ve
.Sh "Elements of the interpreter"
.IX Subsection "Elements of the interpreter"
The work of the interpreter has two main stages: compiling the code
into the internal representation, or bytecode, and then executing it.
\&\*(L"Compiled code\*(R" in perlguts explains exactly how the compilation stage
happens.
.PP
Here is a short breakdown of perl's operation:
.IP "Startup" 3
.IX Item "Startup"
The action begins in \fIperlmain.c\fR. (or \fIminiperlmain.c\fR for miniperl)
This is very high-level code, enough to fit on a single screen, and it
resembles the code found in perlembed; most of the real action takes
place in \fIperl.c\fR
.Sp
First, \fIperlmain.c\fR allocates some memory and constructs a Perl
interpreter:
.Sp
.Vb 9
\&    1 PERL_SYS_INIT3(&argc,&argv,&env);
\&    2
\&    3 if (!PL_do_undump) {
\&    4     my_perl = perl_alloc();
\&    5     if (!my_perl)
\&    6         exit(1);
\&    7     perl_construct(my_perl);
\&    8     PL_perl_destruct_level = 0;
\&    9 }
.Ve
.Sp
Line 1 is a macro, and its definition is dependent on your operating
system. Line 3 references \f(CW\*(C`PL_do_undump\*(C'\fR, a global variable \- all