Getting the line number and filename is relatively easy:

sub trace {
  my($package, $filename, $line) = caller;
  # ...
}
[download]

You can also get the subroutine its in. See the docs for caller.

Getting the names of the relevant variables is much harder, because perl does not such a convinent mechanism for compile-time expanded macros as C. However there are things called source filters, and the Filter::Simple module provides a nice interface to them. So, we can use that to make a module that adds a TRACE() macro:

package TraceMacro;

use Filter::Simple;

FILTER_ONLY 
   code => sub {
s/TRACE\(\s*([^)]+)\s*\)/__PACKAGE__."::_trace(q($1),$1)"/eg; };
# replace each TRACE(...) with <this package>::_trace(q(...),...)

sub _trace {
  my($names,@values) = @_;
  my @names = split /\s*,\s*/, $names; # extract varnames
  my($package,$file,$line) = caller;
  foreach my $i(0..$#names) {
    print STDERR "$file ($line): $names[$i]:'$values[$i]'";
  }
}
[download]

(The module just needs to be saved appropriately to a file called by the name of Package.pm where Package is whatever's specified by the package declaration. (You could change that.))

This has the side-effect of allowing arbitrary expressions instead of just variable names.

update: Usage would be like:

use TraceMacro;

# ...
TRACE( $foo, $bar );
[download]

Outstanding! Everything I wanted and an object lesson in creating my first package, which I didnt really think I was up for yet but this looks simple enough that even I can do it! Thankyou. Anyone with a spare vote handy, give it to this man.

Of course, it will start out as cut&paste for now, but you gave me enough hints for possibilities that I can add (like sub name) to encourage me to investigate the references.

To other responders:

I am aware of the debugger and use it if I get something that needs it, but while im just cranking code out, sticking a TRACE in various places and running the prog is a nice quick way of checking things are doing what I expect or not.

Sorry for the second post here but reading the code I thought of one more feature that may be possible.and will try to work out for myself, but I am unsure of the side effects.

If a SINGLE value is passed, how hard would it be to have it eval the passed expression and then return that from _trace()?

That way, the TRACE macro could be used in-situ in the code, and by a suitable test of some flag (possibly the systems debug settings) either Trace or not trace and the program would still fuction (possibly inefficiently).

Does this thought have any merit?

Well, perl does have the -p option which will throw your Perl program through the C preprocessor....

You have to be careful though, as the # character also starts a Perl comment.

Abigail

Here is a simple example using -P. The program should be run as follows perl -P program.pl and it requires a pre-processor on the target system:

    #!/usr/bin/perl -w

    use strict;

    #define TRACE(x) print "$0 line ". __LINE__ .":\t". x ." = ". eval
+(x). "\n";

    my $foo = 7;
    TRACE('$foo');

    $foo *= $foo;
    TRACE('$foo');

    __END__
    Prints:

    /tmp/test.pl line 8:   $foo = 7
    /tmp/test.pl line 11:  $foo = 49
[download]

--
John.

The TRACE() macro is very like warn $fred, $bill, $!;, except that printing the names of the variables doesn't happen. Package globals do have names that are kept in the symbol table, but not lexicals. You can fiddle with symrefs if you must have the names, but that is a bad habit. Better to just give them explicitly as string arguments to warn

$ perl -e 'my $foo="bar"; warn q/$foo is /, $foo, $!'
$foo is bar at -e line 1.
[download]

I've been playing with the -D flag to perl, which requires a debugging build. You can get lots of very explicit info about a program that way, but maybe more than you are asking for.

After Compline,
Zaxo

  print __FILE__ . " (" . __LINE__ . "): " .
    "(your variable names and values here)\n";
[download]

This presumes that you can't use the Perl debugger to track down your problem. The debugger is a little intimidating, but it's a little cleaner and neater (not to mention way more flexible) to use when tracking down problems.

--t. alex

"Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

Update Abigail's suggestion is much cooler -- it gets Perl to take care of the file name and line numbering detail.

It's really a preference between commenting out code that's no longer needed and just disabling it with the $debug flag. Your choice.

Or you would just use:

    warn "Your variable names and values here" if $debug;
[download]

and Perl will supply the file name and line number for you.

By toggling the $debug variable, you can control whether the program prints debugging messages or not.

Abigail