Front page | perl.perl5.porters |
Postings from March 2000
[PATCH] perldebug.pod
From:
Tom Christiansen
Date:
March 22, 2000 19:08
Subject:
[PATCH] perldebug.pod
Message ID:
7457.953780875@chthon
The debugger code is frightfully screwed when it comes to executing
under -W. You see, it's so incredibly far from being -w clean that
you can't even WATCH the warnings scroll by. Simple typing "perl
-Wde 0" makes it go berserk. This needs to be redone. Meanwhile,
here's a peccavi for the BUGS section. I've also fixed up some
random fontery.
--tom
--- pod/perldebug.pod Sat Mar 18 23:27:43 2000
+++ /tmp/perldebug.pod Wed Mar 22 19:59:15 2000
@@ -68,7 +68,7 @@
=item p expr
Same as C<print {$DB::OUT} expr> in the current package. In particular,
-because this is just Perl's own B<print> function, this means that nested
+because this is just Perl's own C<print> function, this means that nested
data structures and objects are not dumped, unlike with the C<x> command.
The C<DB::OUT> filehandle is opened to F</dev/tty>, regardless of
@@ -211,7 +211,7 @@
is specified, it's evaluated each time the statement is reached: a
breakpoint is taken only if the condition is true. Breakpoints may
only be set on lines that begin an executable statement. Conditions
-don't use B<if>:
+don't use C<if>:
b 237 $x > 30
b 237 ++$count237 < 11
@@ -416,7 +416,7 @@
=item ||dbcmd
-Same as C<|dbcmd> but DB::OUT is temporarily B<select>ed as well.
+Same as C<|dbcmd> but DB::OUT is temporarily C<select>ed as well.
=item = [alias value]
@@ -934,8 +934,11 @@
You cannot get stack frame information or in any fashion debug functions
that were not compiled by Perl, such as those from C or C++ extensions.
-If you alter your @_ arguments in a subroutine (such as with B<shift>
-or B<pop>, the stack backtrace will not show the original values.
+If you alter your @_ arguments in a subroutine (such as with C<shift>
+or C<pop>, the stack backtrace will not show the original values.
+
+The debugger does not currently work in conjunction with the B<-W>
+command-line switch, because it itself is not free of warnings.
If you're in a slow syscall (like C<wait>ing, C<accept>ing, or C<read>ing
from your keyboard or a socket) and haven't set up your own C<$SIG{INT}>
-
[PATCH] perldebug.pod
by Tom Christiansen