perlhack.pod

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

	  $size == $MF{$file}[1] && $mtime == $MF{$file}[2] and next;
	  printf "%4s %-34s %8d %9d  %8d %9d\n",
	      $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;
	  }
      }

though this is not perfect. It could be improved with checking
file checksums before updating. Not all NFS systems support
reliable utime support (when used over the NFS).

=back

=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 C<diff -c> 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.

Presuming you are in a directory where your patches reside, you can
get them in sync with

 # rsync -avz rsync://public.activestate.com/perl-current-diffs/ .

This makes sure the latest available patch is downloaded to your
patch directory.

It's then up to you to apply these patches, using something like

 # last="`cat ../perl-current/.patch`.gz"
 # rsync -avz rsync://public.activestate.com/perl-current-diffs/ .
 # find . -name '*.gz' -newer $last -exec gzcat {} \; >blead.patch
 # cd ../perl-current
 # patch -p1 -N <../perl-current-diffs/blead.patch

or, since this is only a hint towards how it works, use CPAN-patchaperl
from Andreas K鰊ig to have better control over the patching process.

=back

=head2 Why rsync the source tree

=over 4

=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.

=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 C<patch> program does not understand how to deal with new files,
files with 8-bit characters, or files without trailing newlines.

=back

=head2 Why rsync the patches

=over 4

=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.

In case you try to keep in pace on 5 different machines, for which
only one of them has access to the WAN, rsync'ing all the source
trees should than be done 5 times over the NFS. Having
rsync'ed the patches only once, I can apply them to all the source
trees automatically. Need you say more ;-)

=item It's a good reference

If you do not only like to have the most recent development branch,
but also like to B<fix> 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.

The file B<Changes> 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, ...).

You can use the patches later as a kind of search archive.

=over 4

=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.

=item Finding how to fix a bug

If you've found I<where> 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.

=item Finding the source of misbehaviour

When you keep in sync with bleadperl, the pumpking would love to
I<see> 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 OK
report to I<[e-mail]>. (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 C<perl.ok>, which you can
than take to your favourite mailer and mail yourself).

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 B<before> sending in the bug,
which will help all the other porters in finding the solution.

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.

=back

If searching the patches is too bothersome, you might consider using
perl's bugtron to find more information about discussions and
ramblings on posted bugs.

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.

=back

=head2 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 I<overwrite> your
local versions!

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.

Perl's F<Configure> 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 F<perl-rsync> directory.  In the directory
above that one, you can execute the following commands:

  mkdir perl-dev
  cd perl-dev
  ../perl-rsync/Configure -Dmksymlinks -Dusedevel -D"optimize=-g"

This will start the Perl configuration process.  After a few prompts,
you should see something like this:

  Symbolic links are supported.

  Checking how to test for symbolic links...
  Your builtin 'test -h' may be broken.
  Trying external '/usr/bin/test -h'.
  You can test for symbolic links with '/usr/bin/test -h'.

  Creating the symbolic links...
  (First creating the subdirectories...)
  (Then creating the symlinks...)

The specifics may vary based on your operating system, of course.
After you see this, you can abort the F<Configure> script, and you
will see that the directory you are in has a tree of symlinks to the
F<perl-rsync> directories and files.

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:

    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
    }

Replace "vi" with your favorite flavor of editor.

Here is another function which will quickly generate a patch for the
files which have been edited in your symlink tree:

    mkpatchorig() {
	local diffopts
	for f in `find . -name '*.orig' | sed s,^\./,,`
	do
	    case `echo $f | sed 's,.orig$,,;s,.*\.,,'` in
		c)   diffopts=-p ;;
		pod) diffopts='-F^=' ;;
		*)   diffopts= ;;
	    esac
	    diff -du $diffopts $f `echo $f | sed 's,.orig$,,'`
	done
    }

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.

This function assumed a GNU diff, and may require some tweaking for
other diff variants.

=head2 Perlbug administration

There is a single remote administrative interface for modifying bug status,
category, open issues etc. using the B<RT> bugtracker system, maintained
by Robert Spier.  Become an administrator, and close any bugs you can get
your sticky mitts on:

	http://bugs.perl.org/

To email the bug system administrators:

	"perlbug-admin" <[e-mail]>

=head2 Submitting patches

Always submit patches to I<[e-mail]>.  If you're
patching a core module and there's an author listed, send the author a
copy (see L<Patching a core module>).  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' I<makepatch>
(available from I<CPAN/authors/id/JV/>).  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
I<Porting/patching.pod> file in the Perl source distribution.  Please
patch against the latest B<development> version. (e.g., even if you're
fixing a bug in the 5.8 track, patch against the latest B<development>
version rsynced from rsync://public.activestate.com/perl-current/ )

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.

Your patch should update the documentation and test suite.  See
L<Writing a test>.  If you have added or removed files in the distribution,
edit the MANIFEST file accordingly, sort the MANIFEST file using
C<make manisort>, and include those changes as part of your patch.

Patching documentation also follows the same order: if accepted, a patch
is first applied to B<development>, and if relevant then it's backported
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
Perl (if you can't get Perl to work, send mail to the address
I<[e-mail]> or I<[e-mail]>).  Reporting bugs through
I<perlbug> 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.

The CPAN testers ( http://testers.cpan.org/ ) are a group of
volunteers who test CPAN 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
L<http://search.cpan.org/dist/Test-Smoke>. In order to start smoke
testing CPAN modules visit L<http://search.cpan.org/dist/CPAN-YACSmoke/>
or L<http://search.cpan.org/dist/POE-Component-CPAN-YACSmoke/> or
L<http://search.cpan.org/dist/CPAN-Reporter/>.

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.

If after all this you still think you want to join the perl5-porters
mailing list, send mail to I<[e-mail]>.  To
unsubscribe, send mail to I<[e-mail]>.

To hack on the Perl guts, you'll need to read the following things:

=over 3

=item L<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