http://qs321.pair.com?node_id=708946


in reply to Re: RFC: Accelerated stepping
in thread RFC: Accelerated stepping

From time to time, I wonder why n doesn't jump map, grep, etc.

Everytime a code block is entered, the Perl core delivers control to the debugger. Now it seems to me, when 'n' was created, some additional logic has been implemented, in order to shortcut the execution of subroutines, but not code blocks (like from map/grep/sort) in general.
So I could even file a bug report :-)). That depends on your viewpoint, of course.

Update: I think the patch could be made better, if the general problem of shortcutting code blocks is solved. Then also operators (any, all, ...) from List::Utils and friends could be stepped over. So, I will look into it again. Stay tuned...

Therefore, I suggest that you try p5p, explain them grinder's comments about backwards compatibility and the idea of using N as an alternative.

That is a great suggestion, thanks. I will ask them how serious they value backward compatibility in this case. Either it can be changed, or there will be a new command then.

I will also try out, if the '=' alias can be used to redefine 'n'.

Finally, the 'Perl Hacks' book has hack #59 for writing your own debugger commands or modifying existing ones. But since many (most?) users want the change, it might be better to change it once in the debugger source.

Replies are listed 'Best First'.
Re^3: RFC: Accelerated stepping
by Anonymous Monk on Sep 05, 2008 at 07:11 UTC
    Oh, I think it's a good idea to change the source. In terms of backward compatibility you've still got 's' (step into), while the 'n' (next statement) is always a pain when 'n'-ing over sort and map blocks. Of course you can 'c' (continue) to a new location (line), but then you have to stop, break your flow, and work out where you want to go specifically. It's nice to see someone prepared to delve into those murky depths to fix this behaviour to be more intuitive at last. R.
[reply]
      Oh, I think it's a good idea to change the source. In terms of backward compatibility you've still got 's' (step into), while the 'n' (next statement) is always a pain when 'n'-ing over sort and map blocks. Of course you can 'c' (continue) to a new location (line), but then you have to stop, break your flow, and work out where you want to go specifically. It's nice to see someone prepared to delve into those murky depths to fix this behaviour to be more intuitive at last.

      Richard Foley.

      ps. sry, didn't mean to post anonymously earlier :-)

[reply]
        I just found out, that if you modify the example Perl code from 
        if (0 < scalar grep { $_ == 9 } (1..10)) {

        [download]
        to 
        if (0 < scalar grep(sub { $_ == 9 }, (1..10))) {

        [download]
        then 'n' does step over the whole grep command at once!

        Update: thanks to tye for noticing an error in the above code. Obviously the code 

        if (0 < scalar grep(1, (1..10))) {

        [download]
        does not involve a code block, and consequently is stepped over with a single 'n'.

        For map and sort the behavior looks a bit different, since the operator prototypes are not orthogonal :-(.
        sort wants something like ::mycmp (no sigil, so what is the name of that type?).
        These examples 

        print '1. ', (join q{,}, sort               qw(a z b y)), "\n";
print '2. ', (join q{,}, sort { $a cmp $b } qw(a z b y)), "\n";
print '3. ', (join q{,}, sort(::mycmp       qw(a z b y))), "\n";

sub mycmp
{
    return $a cmp $b;
}

        [download]
        work, and will give these results:
        example '1.' will be stepped over by 'n', while examples 2./3. are non stepped over with 'n'.
        So, only if you supply your own comparison, 'n' steps into it.

        The same goes for map, except that map only works with a code block.

        This 

        # panics
print 'map2', (join q{,}, map(::myuc     qw(a z b y))), "\n";

sub myuc
{
    return uc($_[0]);
}

        [download]
        causes a panic from the Perl interpreter during compile time!

        Finally the operators from List::Util and List::MoreUtils (c implementation) are stepped over with 'n'.

        So I think the inconsistency in behavior is caused by the Perl interpreter, namely the treatment of code references/blocks as parameters of operators. So the behavior should better be changed there. I will contact p5p.

[reply]
[d/l]
[select]

In Section Meditations