And now that I've figured that out, I've found the wisdom I seek, based on the search result changing state

w $main::{"_<".(caller 2)[1]}[(caller 2)[2]] =~ /\bprint\b/
[download]

1. not having to call "caller 2" twice
2. have the expression only change value when it first hits the "print" statment, and not when it goes to the next line- perhaps by using the flip-flop operator
3. somehow using perl5db's English-named variables

OK changing it to (caller 3) made it work for me! =)

  DB<100>  w $main::{"_<".(caller 3)[1]}[(caller 3)[2]] =~ /\bprint\b/
  DB<101> r
0
1
Watchpoint 0:    $main::{"_<".(caller 3)[1]}[(caller 3)[2]] =~ /\bprin
+t\b/ changed:
    old value:    ''
    new value:    '1'
main::(tst.pl:13):    print $x++;
[download]

my suggestion is to define a new debugger command for "global-break-line" via an alias like bl in your '.perldb'.

Like that  bl REGEX is translated to w @{ [ DB::breakline(regex) ] }

sub DB::breakline { } is also defined in '.perldb' and handles the details to access the line's source and to return a new value.

tomorrow more!

Cheers Rolf

( addicted to the Perl Programming Language)

We must have different versions of perl, with different call-stack depths in our debuggers.

Using a counter is a simple way of having the state change only before the matching line, and not after:

w $::ctr+=$::{"_<".(caller 3)[1]}[(caller 3)[2]] =~ /\bprint\b/
[download]

The bistable flip-flop seems like it should be perfect for this case, if you take care to use a non-constant always-true expression for the right hand side. Seems like it should. I can't get it to work properly. And now I'm spending more time playing with the debugger than debugging!

But it sure is a fun challenge.

This really works???

Anyway I think I have a better idea, you can use this hack to evaluate code within a pseudo-var

  DB<100> w @{[$z++]}
[download]

this watch-point will break at each line, cause the value changes.

Now if you include a condition to change only, if your filter matches, you got what you need! :)

edit

  DB<101> w @{[$z++]}

  DB<102> r
0
Watchpoint 0:    @{[$z++]} changed:
    old value:    '0'
    new value:    '1'
main::(tst.pl:12):    say $x++;
  DB<102> r
1
Watchpoint 0:    @{[$z++]} changed:
    old value:    '1'
    new value:    '2'
main::(tst.pl:13):    print $x++;
[download]

Cheers Rolf

( addicted to the Perl Programming Language)

I had the same thought about overriding "print" but that's one of the core ops that it won't work for, since there's no prototype letting the parser treat it like a sub. (And there's no CORE::print to break on either).

Possible to completely hack a solution along the lines of perl -pi.bak -e "s/\bprint\b/$DB_single=1;\nprint/" or do something exceedingly clever with B::Util- though simply adding a few breakpoints by hand will do all I need to do with far less room for making things worse!

ps. thanks for the link to obsidianrook, I always enjoy those presentations!

> no prototype letting the parser treat it like a sub.

true, most probably cause of it's magic behavior as handle-method. Though looking into IO::Handle might help.

Anyway, I don't know what your prints are supposed to do, but before relying on source-filtering I'd rather rename them like dbout or out or say.

The following code breaks on each output, simply uncommenting use feature disables this behavior.

#use feature 'say';

sub say {
  print @_,"\n";
  no warnings 'once';
  $DB::single=1;
}

say $x++;
say $x++;
say $x++;
say $x++;
say $x++;
[download]

> ps. thanks for the link to obsidianrook, I always enjoy those presentations!

Well, better thank doom directly! =)

Cheers Rolf

( addicted to the Perl Programming Language)