=head2 Writing Your Own Debugger
=head3 Environment Variables
-
+
The C<PERL5DB> environment variable can be used to define a debugger.
For example, the minimal "working" debugger (it actually doesn't do anything)
consists of one line:
-
+
sub DB::DB {}
It can easily be defined like this:
-
+
$ PERL5DB="sub DB::DB {}" perl -d your-script
Another brief debugger, slightly more useful, can be created
This debugger prints a number which increments for each statement
encountered and waits for you to hit a newline before continuing
to the next statement.
-
+
The following debugger is actually useful:
-
+
{
package DB;
sub DB {}
open FILE, "<", " file "; # filename is " file "
open FILE, ">", ">file"; # filename is ">file"
-
It may be a lot clearer to use sysopen(), though:
unpack() C's C<struct {char c; double d; char cc[2]}> one may need to
use the template C<C x![d] d C[2]>; this assumes that doubles must be
aligned on the double's size.
-
+
For alignment commands C<count> of 0 is equivalent to C<count> of 1;
both result in no-ops.
-
+
=item *
A comment in a TEMPLATE starts with C<#> and goes to the end of line.
gets invoked in which platform is simply a big mess that needs to be
untangled. Secondly, the effects are apparently not standard across
platforms, (if you first set $< and then $>, or vice versa, being
-uid==euid== zero, or just euid==zero, or as a normal user, what are
+uid == euid == zero, or just euid == zero, or as a normal user, what are
the results?). The test suite not (usually) being run as root means
that these things do not get much testing. Thirdly, there's quite
often a third uid called saved uid, and Perl has no knowledge of that
back any real and effective uids.) As an example, to change also the
saved uid, one needs to set the real and effective uids B<twice>-- in
most systems, that is: in HP-UX that doesn't seem to work.
-
+
=head2 Custom opcodes
Have a way to introduce user-defined opcodes without the subroutine call
characters such as length(), substr() or index() can work B<much>
faster when the underlying data are byte-encoded. Witness the
following benchmark:
-
+
% perl -e '
use Benchmark;
use strict;
LENGTH_U: 2 wallclock secs ( 2.11 usr + 0.00 sys = 2.11 CPU) @ 12155.45/s (n=25648)
SUBSTR_B: 3 wallclock secs ( 2.16 usr + 0.00 sys = 2.16 CPU) @ 374480.09/s (n=808877)
SUBSTR_U: 2 wallclock secs ( 2.11 usr + 0.00 sys = 2.11 CPU) @ 6791.00/s (n=14329)
-
+
The numbers show an incredible slowness on long UTF-8 strings and you
should carefully avoid to use these functions within tight loops. For
example if you want to iterate over characters, it is infinitely
You see, the algorithm based on substr() was faster with byte encoded
data but it is pathologically slow with UTF-8 data.
-
+
=head1 SEE ALSO
L<perluniintro>, L<encoding>, L<Encode>, L<open>, L<utf8>, L<bytes>,