that describe the individual changes that have happened since the last
public release are available at this location:
- http://public.activestate.com/gsar/APC/
- ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/
+ http://public.activestate.com/pub/apc/
+ ftp://public.activestate.com/pub/apc/
If you're looking for a particular change, or a change that affected
a particular set of files, you may find the B<Perl Repository Browser>
and you have rsync installed and available, you can "upgrade" to
the bleadperl using:
- # rsync -avz rsync://ftp.linux.activestate.com/perl-current/ .
+ # rsync -avz rsync://public.activestate.com/perl-current/ .
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
the rsync. Once you are sure that the rsync is running correctly,
run it with the --delete and the --dry-run options like this:
- # rsync -avz --delete --dry-run rsync://ftp.linux.activestate.com/perl-current/ .
+ # rsync -avz --delete --dry-run rsync://public.activestate.com/perl-current/ .
This will I<simulate> an rsync run that also deletes files not
present in the bleadperl master copy. Observe the results from
Presuming you are in a directory where your patches reside, you can
get them in sync with
- # rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
+ # 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=`ls -t *.gz | sed q`
- # rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
+ # 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
=item Exception handing
-Perl's exception handing (ie C<die> etc) is built on top of the low-level
+Perl's exception handing (i.e. C<die> etc) is built on top of the low-level
C<setjmp()>/C<longjmp()> C-library functions. These basically provide a
-way to capture the current PC and SP registers and later restore them; ie
+way to capture the current PC and SP registers and later restore them; i.e.
a C<longjmp()> continues at the point in code where a previous C<setjmp()>
was done, with anything further up on the C stack being lost. This is why
code should always save values using C<SAVE_FOO> rather than in auto
maintainer keep the CPAN version in sync with the core version without
constantly scanning p5p.
+The list of maintainers of core modules is usefully documented in
+F<Porting/Maintainers.pl>.
+
=head2 Adding a new function to the core
If, as part of a patch to fix a bug, or just because you have an
(Only in Tru64) Run all the tests using the memory leak + naughty
memory access tool "Third Degree". The log files will be named
-F<perl3.log.testname>.
+F<perl.3log.testname>.
=item test.torture torturetest
converts C<new_SV()> from a macro into a real function, so you can use
your favourite debugger to discover where those pesky SVs were allocated.
+=head2 PERL_MEM_LOG
+
+If compiled with C<-DPERL_MEM_LOG>, all Newx() and Renew() allocations
+and Safefree() in the Perl core go through logging functions, which is
+handy for breakpoint setting. If also compiled with C<-DPERL_MEM_LOG_STDERR>,
+the allocations and frees are logged to STDERR (or more precisely, to the
+file descriptor 2) in these logging functions, with the calling source code
+file and line number (and C function name, if supported by the C compiler).
+
+This logging is somewhat similar to C<-Dm> but independent of C<-DDEBUGGING>,
+and at a higher level (the C<-Dm> is directly at the point of C<malloc()>,
+while the C<PERL_MEM_LOG> is at the level of C<New()>).
+
=head2 Profiling
Depending on your platform there are various of profiling Perl.