Croak if gv_init doesn't know how to create a typeglob from that type

[p5sagit/p5-mst-13.2.git] / pod / perlhack.pod

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index f90c48b..f4bbb69 100644 (file)
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -216,8 +216,8 @@ 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:
 
-    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>
@@ -256,7 +256,7 @@ Presuming you are in the directory where your perl source resides
 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
@@ -267,7 +267,7 @@ 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:
 
- # 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
@@ -354,7 +354,7 @@ 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://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.
@@ -362,7 +362,7 @@ 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
@@ -877,9 +877,9 @@ retrieves the return op from it, and returns it.
 
 =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
@@ -1858,6 +1858,9 @@ the module maintainer (with a copy to p5p).  This will help the module
 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
@@ -2079,7 +2082,7 @@ F<testname.valgrind>.
 
 (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
 
@@ -2468,6 +2471,19 @@ memory usage, so it shouldn't be used in production environments. It also
 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.