Re: RFC: Accelerated stepping

I think it's great to see people daring to dive into the unplumbed depths of perl5db.pl. Few who have ventured there remained sane enough to describe their experiences afterwards.

I think the likely response from p5p will to that you cannot change the behaviour of n for backwards compatibility reasons. The fact that you can no longer step through the innards of a map or grep is too much of loss. That said, I think the concept has great merit. To that end, an approach that is more likely to succeed would be to introduce a new command letter. N is currently free (according to my copy of bleadperl).

As a minor stylistic issue, the Perl core hasn't drunk the PBP kool-aid, and thus you would probably want to write your check as the more compact

if ($dbline[$line] =~ /\b(?:grep|map|sort)\b/) {...

You also don't need to capture it. I also wonder if that will pick up a "map" in a quoted string or a comment...

In a similar vein, I think my @sublast = split m{-}xms, $sub{$sub} looks slightly silly.

split /-/ is fine.

update: I am a bit thick sometimes. It took tye's reply for me to realise that there is no loss of functionality. So the N hack isn't necessary. So what's left is purely a matter of code style.

• another intruder with the mooring in the heart of the Perl

Comment on Re: RFC: Accelerated stepping Select or Download Code

Replies are listed 'Best First'.
Re^2: RFC: Accelerated stepping by hexcoder (Deacon) on Sep 02, 2008 at 14:40 UTC
Thanks, Actually I first thought of introducing a new 'N' or even 'nn' command, but I then considered the difference to 'n' too miniscule to bother with it. The fact that you can no longer step through the innards of a map or grep is too much of loss. It is possible, if you use 's'. Regarding the coding style, yes, when in Rome, talk like romans do, so when in Perl4 code talk like Perl4 coders did :-). BTW: is perl5db.pl required to be backward compatible to Perl 4.x??	[reply]
Re^3: RFC: Accelerated stepping by grinder (Bishop) on Sep 02, 2008 at 20:24 UTC
I then considered the difference to 'n' too miniscule to bother with it. Others won't. is perl5db.pl required to be backward compatible to Perl 4.x Well of course not. It uses lexical variables for starters. You are looking at possibly the oldest, continually tweaked file in the Perl distribution though. It has enough cruft and differing code styles and idioms without adding one more. • another intruder with the mooring in the heart of the Perl	[reply]
Re^4: RFC: Accelerated stepping (p5p) by tye (Sage) on Sep 03, 2008 at 03:45 UTC
Fixing 'n' to do what it always should have with map/grep/sort would be a very welcome change. As already pointed out, there is no loss of functionality. Instead of 'n' and 's' both stepping into the map/grep/sort (which is almost never what I want to do), 's' does the old behavior and 'n' does something much better. Of course, I sent in a near-trivial patch to fix "o warn=0" and got quite bizarre responses from p5p and I've come to expect bizarre responses from p5p so if your prediction is correct it wouldn't be anything "new" from my perspective. But I still think it would be a senseless form of backward compatibility. Perhaps I should point out that my patch for "o warn=0" restores backward compatability with "O warn=0" from before the whole debugger interface was jumbled around for some reason. It might motivate somebody to apply my two-line patch due to the occasional extreme devotion to backward compatability. But I doubt it. - tye	[reply]
Re^5: RFC: Accelerated stepping (p5p) by hexcoder (Deacon) on Sep 04, 2008 at 06:43 UTC
Re^6: RFC: Accelerated stepping (p5p) by tye (Sage) on Sep 04, 2008 at 07:24 UTC


XP is just a number
	PerlMonks