NAME
PDL::Dbg -- functions to support debugging of PDL scripts
DESCRIPTION
This packages implements a couple of functions that should come in handy when debugging your PDL scripts. They make a lot of sense while your doing rapid prototyping of new PDL code, let's say inside the perldl shell.
vars
perldl> vars
This function prints some information about the pdls currently found in the main symbol table. This comes in quite handy when you are not quite sure which pdls you have already defined, what data they may hold and maybe how they are related (parent/child, etc.). For every pdl found it then prints some information. This information is generated by a sub routine specified in the global variable $PDL::Dbg::varinfo_sub
. For most purposes the default subroutine will be sufficient but in some circumstances you might want to use your own customised routine. The subroutine should take one input argument (normally a PDL object) and return a string with some information about it (with no trailing newline!). You can specify that routine in three different ways:
call vars with a hash argument as
vars( 'sub' => \&myroutine );
-
use C<set_varinfo_handler> (see below) to specify the subroutine/and a classname pattern
or (least preferable) directly assign a ref to your routine to <$PDL::Dbg::varinfo_sub> before calling
vars
Another argument currently accepted by vars
is the 'class' argument. This argument should be used when you are not (only) interested in pdls but rather in objects derived from it that have been blessed into another class. By default vars
will print info about all symbols in the current symbol table whose ref
matches the classpattern (defaults to $PDL::name
(indicating PDL objects) until $PDL::Dbg::classpattern
is changed). You can specify your own class name to print your own derived objects or you can specify a regular expression matching several classes. In general, you should then also supply your own sub to print the relevant info about these objects, e.g.:
vars('class' => '(PDL)|(MYPDL)',
'sub' => \&mysub);
Finally, you can explicitly specify the package in which you want to look for currently defined pdls (or other objects depending on the current classpattern). To this end use the 'package'
argument. By default the package from which vars
was invoked is used.
Most of the time this will be package main::
(when working interactively in the perldl
shell). Note that vars
does not show any lexically scoped my
variables.
vars('class' => '(PDL)|(MYPDL)',
'sub' => \&mysub,
'package' => 'PDL::Lib::Goodies');
vars
returns the number of objects found upon completion.
set_varinfo_handler
my ($ssave,$pattern) = set_varinfo_handler(\&mysub,'(^PDL$)|(^PLOT$)');
vars;
set_varinfo_handler($ssave,$pattern); # restore previous settings
A little helper to optionally install a new info handler for the vars
function and optionally a new pattern for class matching. Takes the new sub and a new class matching pattern as optional first and second argument. When invoked in list context returns the previous subroutine reference and current classname pattern otherwise just the sub routine reference. Can be used to modify the vars
info handler (and optionally pattern) temporarily, see example above. Otherwise, when calling with no arguments can be used to just get the current handler and pattern
px
$b = $a->slice(',(2),')->thread2(3)->px->mv(1,6);
This PDL method takes a pdl object as input and returns the same object without mofifications. Therefore it can be inserted into a chain of indexing command without changing the result. However, if the debug flag $PDL::debug
is set it prints info about the current dimensions, thread IDs, etc as a side effect and can therefore be useful to debug chains of indexing commands as those in the above example. If $PDL::debug
is not set it just remains silent.
BUGS
There are probably some. Please report if you find any. Bug reports should be sent to the PDL mailing list perldl@jachw.hawaii.edu.
AUTHOR
Copyright(C) 1997 Christian Soeller (csoelle@sghms.ac.uk).