perlhack.1

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

thrown away by someone in the future?
.IP "Is there enough documentation?" 4
.IX 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.
.IP "Is there another way to do it?" 4
.IX Item "Is there another way to do it?"
Larry said "Although the Perl Slogan is \fIThere's More Than One Way
to Do It\fR, I hesitate to make 10 ways to do something".  This is a
tricky heuristic to navigate, though\*(--one man's essential addition is
another man's pointless cruft.
.IP "Does it create too much work?" 4
.IX Item "Does it create too much work?"
Work for the pumpking, work for Perl programmers, work for module
authors, ...  Perl is supposed to be easy.
.IP "Patches speak louder than words" 4
.IX Item "Patches speak louder than words"
Working code is always preferred to pie-in-the-sky ideas.  A patch to
add a feature stands a much higher chance of making it to the language
than does a random feature request, no matter how fervently argued the
request might be.  This ties into \*(L"Will it be useful?\*(R", as the fact
that someone took the time to make the patch demonstrates a strong
desire for the feature.
.PP
If you're on the list, you might hear the word \*(L"core\*(R" bandied
around.  It refers to the standard distribution.  \*(L"Hacking on the
core\*(R" means you're changing the C source code to the Perl
interpreter.  \*(L"A core module\*(R" is one that ships with Perl.
.Sh "Keeping in sync"
.IX Subsection "Keeping in sync"
The source code to the Perl interpreter, in its different versions, is
kept in a repository managed by a revision control system ( which is
currently the Perforce program, see http://perforce.com/ ).  The
pumpkings and a few others have access to the repository to check in
changes.  Periodically the pumpking for the development version of Perl
will release a new version, so the rest of the porters can see what's
changed.  The current state of the main trunk of repository, and patches
that describe the individual changes that have happened since the last
public release are available at this location:
.PP
.Vb 2
\&    http://public.activestate.com/pub/apc/
\&    ftp://public.activestate.com/pub/apc/
.Ve
.PP
If you're looking for a particular change, or a change that affected
a particular set of files, you may find the \fBPerl Repository Browser\fR
useful:
.PP
.Vb 1
\&    http://public.activestate.com/cgi\-bin/perlbrowse
.Ve
.PP
You may also want to subscribe to the perl5\-changes mailing list to
receive a copy of each patch that gets submitted to the maintenance
and development \*(L"branches\*(R" of the perl repository.  See
http://lists.perl.org/ for subscription information.
.PP
If you are a member of the perl5\-porters mailing list, it is a good
thing to keep in touch with the most recent changes. If not only to
verify if what you would have posted as a bug report isn't already
solved in the most recent available perl development branch, also
known as perl-current, bleading edge perl, bleedperl or bleadperl.
.PP
Needless to say, the source code in perl-current is usually in a perpetual
state of evolution.  You should expect it to be very buggy.  Do \fBnot\fR use
it for any purpose other than testing and development.
.PP
Keeping in sync with the most recent branch can be done in several ways,
but the most convenient and reliable way is using \fBrsync\fR, available at
ftp://rsync.samba.org/pub/rsync/ .  (You can also get the most recent
branch by \s-1FTP\s0.)
.PP
If you choose to keep in sync using rsync, there are two approaches
to doing so:
.IP "rsync'ing the source tree" 4
.IX Item "rsync'ing the source tree"
Presuming you are in the directory where your perl source resides
and you have rsync installed and available, you can \*(L"upgrade\*(R" to
the bleadperl using:
.Sp
.Vb 1
\& # rsync \-avz rsync://public.activestate.com/perl\-current/ .
.Ve
.Sp
This takes care of updating every single item in the source tree to
the latest applied patch level, creating files that are new (to your
distribution) and setting date/time stamps of existing files to
reflect the bleadperl status.
.Sp
Note that this will not delete any files that were in '.' before
the rsync. Once you are sure that the rsync is running correctly,
run it with the \-\-delete and the \-\-dry\-run options like this:
.Sp
.Vb 1
\& # rsync \-avz \-\-delete \-\-dry\-run rsync://public.activestate.com/perl\-current/ .
.Ve
.Sp
This will \fIsimulate\fR an rsync run that also deletes files not
present in the bleadperl master copy. Observe the results from
this run closely. If you are sure that the actual run would delete
no files precious to you, you could remove the '\-\-dry\-run' option.
.Sp
You can than check what patch was the latest that was applied by
looking in the file \fB.patch\fR, which will show the number of the
latest patch.
.Sp
If you have more than one machine to keep in sync, and not all of
them have access to the \s-1WAN\s0 (so you are not able to rsync all the
source trees to the real source), there are some ways to get around
this problem.
.RS 4
.IP "Using rsync over the \s-1LAN\s0" 4
.IX Item "Using rsync over the LAN"
Set up a local rsync server which makes the rsynced source tree
available to the \s-1LAN\s0 and sync the other machines against this
directory.
.Sp
From http://rsync.samba.org/README.html :
.Sp
.Vb 5
\&   "Rsync uses rsh or ssh for communication. It does not need to be
\&    setuid and requires no special privileges for installation.  It
\&    does not require an inetd entry or a daemon.  You must, however,
\&    have a working rsh or ssh system.  Using ssh is recommended for
\&    its security features."
.Ve
.IP "Using pushing over the \s-1NFS\s0" 4
.IX Item "Using pushing over the NFS"
Having the other systems mounted over the \s-1NFS\s0, you can take an
active pushing approach by checking the just updated tree against
the other not-yet synced trees. An example would be
.Sp
.Vb 1
\&  #!/usr/bin/perl \-w
\&
\&  use strict;
\&  use File::Copy;
\&
\&  my %MF = map {
\&      m/(\eS+)/;
\&      $1 => [ (stat $1)[2, 7, 9] ];     # mode, size, mtime
\&      } \`cat MANIFEST\`;
\&
\&  my %remote = map { $_ => "/$_/pro/3gl/CPAN/perl\-5.7.1" } qw(host1 host2);
\&
\&  foreach my $host (keys %remote) {
\&      unless (\-d $remote{$host}) {
\&          print STDERR "Cannot Xsync for host $host\en";
\&          next;
\&          }
\&      foreach my $file (keys %MF) {
\&          my $rfile = "$remote{$host}/$file";
\&          my ($mode, $size, $mtime) = (stat $rfile)[2, 7, 9];
\&          defined $size or ($mode, $size, $mtime) = (0, 0, 0);
\&          $size == $MF{$file}[1] && $mtime == $MF{$file}[2] and next;
\&          printf "%4s %\-34s %8d %9d  %8d %9d\en",
\&              $host, $file, $MF{$file}[1], $MF{$file}[2], $size, $mtime;
\&          unlink $rfile;
\&          copy ($file, $rfile);
\&          utime time, $MF{$file}[2], $rfile;
\&          chmod $MF{$file}[0], $rfile;
\&          }
\&      }
.Ve
.Sp
though this is not perfect. It could be improved with checking
file checksums before updating. Not all \s-1NFS\s0 systems support
reliable utime support (when used over the \s-1NFS\s0).
.RE
.RS 4
.RE
.IP "rsync'ing the patches" 4
.IX Item "rsync'ing the patches"
The source tree is maintained by the pumpking who applies patches to
the files in the tree. These patches are either created by the
pumpking himself using \f(CW\*(C`diff \-c\*(C'\fR after updating the file manually or
by applying patches sent in by posters on the perl5\-porters list.
These patches are also saved and rsync'able, so you can apply them
yourself to the source files.
.Sp
Presuming you are in a directory where your patches reside, you can
get them in sync with
.Sp
.Vb 1
\& # rsync \-avz rsync://public.activestate.com/perl\-current\-diffs/ .
.Ve
.Sp
This makes sure the latest available patch is downloaded to your
patch directory.
.Sp
It's then up to you to apply these patches, using something like
.Sp
.Vb 5
\& # last="\`cat ../perl\-current/.patch\`.gz"
\& # rsync \-avz rsync://public.activestate.com/perl\-current\-diffs/ .
\& # find . \-name \*(Aq*.gz\*(Aq \-newer $last \-exec gzcat {} \e; >blead.patch
\& # cd ../perl\-current
\& # patch \-p1 \-N <../perl\-current\-diffs/blead.patch
.Ve
.Sp
or, since this is only a hint towards how it works, use CPAN-patchaperl
from Andreas Ko\*:nig to have better control over the patching process.
.Sh "Why rsync the source tree"
.IX Subsection "Why rsync the source tree"
.IP "It's easier to rsync the source tree" 4
.IX 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.
.IP "It's more reliable" 4
.IX Item "It's more reliable"
While both the rsync-able source and patch areas are automatically
updated every few minutes, keep in mind that applying patches may
sometimes mean careful hand-holding, especially if your version of
the \f(CW\*(C`patch\*(C'\fR program does not understand how to deal with new files,
files with 8\-bit characters, or files without trailing newlines.
.Sh "Why rsync the patches"
.IX Subsection "Why rsync the patches"
.IP "It's easier to rsync the patches" 4
.IX 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
them to all the source trees on the different machines.
.Sp
In case you try to keep in pace on 5 different machines, for which
only one of them has access to the \s-1WAN\s0, rsync'ing all the source
trees should than be done 5 times over the \s-1NFS\s0. Having
rsync'ed the patches only once, I can apply them to all the source
trees automatically. Need you say more ;\-)
.IP "It's a good reference" 4
.IX Item "It's a good reference"
If you do not only like to have the most recent development branch,
but also like to \fBfix\fR bugs, or extend features, you want to dive
into the sources. If you are a seasoned perl core diver, you don't
need no manuals, tips, roadmaps, perlguts.pod or other aids to find
your way around. But if you are a starter, the patches may help you
in finding where you should start and how to change the bits that
bug you.
.Sp
The file \fBChanges\fR is updated on occasions the pumpking sees as his
own little sync points. On those occasions, he releases a tar-ball of
the current source tree (i.e. [e-mail]), which will be an
excellent point to start with when choosing to use the 'rsync the
patches' scheme. Starting with perl@7582, which means a set of source
files on which the latest applied patch is number 7582, you apply all
succeeding patches available from then on (7583, 7584, ...).
.Sp
You can use the patches later as a kind of search archive.
.RS 4
.IP "Finding a start point" 4
.IX Item "Finding a start point"
If you want to fix/change the behaviour of function/feature Foo, just
scan the patches for patches that mention Foo either in the subject,
the comments, or the body of the fix. A good chance the patch shows
you the files that are affected by that patch which are very likely
to be the starting point of your journey into the guts of perl.
.IP "Finding how to fix a bug" 4
.IX Item "Finding how to fix a bug"
If you've found \fIwhere\fR the function/feature Foo misbehaves, but you
don't know how to fix it (but you do know the change you want to
make), you can, again, peruse the patches for similar changes and
look how others apply the fix.
.IP "Finding the source of misbehaviour" 4
.IX Item "Finding the source of misbehaviour"
When you keep in sync with bleadperl, the pumpking would love to
\&\fIsee\fR that the community efforts really work. So after each of his
sync points, you are to 'make test' to check if everything is still
in working order. If it is, you do 'make ok', which will send an \s-1OK\s0
report to \[e-mail]\fR. (If you do not have access to a mailer
from the system you just finished successfully 'make test', you can
do 'make okfile', which creates the file \f(CW\*(C`perl.ok\*(C'\fR, which you can
than take to your favourite mailer and mail yourself).
.Sp
But of course, as always, things will not always lead to a success
path, and one or more test do not pass the 'make test'. Before
sending in a bug report (using 'make nok' or 'make nokfile'), check
the mailing list if someone else has reported the bug already and if
so, confirm it by replying to that message. If not, you might want to
trace the source of that misbehaviour \fBbefore\fR sending in the bug,
which will help all the other porters in finding the solution.
.Sp
Here the saved patches come in very handy. You can check the list of
patches to see which patch changed what file and what change caused
the misbehaviour. If you note that in the bug report, it saves the
one trying to solve it, looking for that point.
.RE
.RS 4
.Sp
If searching the patches is too bothersome, you might consider using
perl's bugtron to find more information about discussions and