accelerated stepping
he...@hexco.de
often during single-stepping I am missing a command like 'n' to step
over not only subroutine calls, but also complete map and grep-commands.
Example:
Instead of
main::(perldb_demo.pl:4): my @a = (1..10);
DB<1> n
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:7): print "found\n";
I would like to use
main::(perldb_demo.pl:4): my @a = (1..10);
DB<1> N
main::(perldb_demo.pl:6): if (0 < scalar grep { $_ == 9 } @a) {
DB<1>
main::(perldb_demo.pl:7): print "found\n";
How could that be done?
I could imagine $DB::single can be set to 3 for this 'accelerated'
stepping.
May I reserve the capital N for that command?
Thanks,
Heiko
--
Richard Foley
> I could imagine $DB::single can be set to 3 for this 'accelerated'
> stepping.
>
It's a good idea.
> May I reserve the capital N for that command?
>
Nearly :-)
I only mean you could use either 'nn' or 'N', equally. To be honest, the
former appeals a little more as an extention to the existing command, while
the latter seems to be a bit more distinct, although I don't actually have
another suggestion for the latter at the moment either. If you implement it
though, I suspect you can use any letter you choose, certainly at first...
--
Richard Foley
Ciao - shorter than aufwiedersehen
he...@hexco.de
> On Fri, Aug 29, 2008 at 3:53 PM, Richard Foley
> <Richar...@rfi.net> wrote:
> > Hi Heiko,
> >
> >> I could imagine $DB::single can be set to 3 for this 'accelerated'
> >> stepping.
> > >
> > It's a good idea.
To Richard:
Afterwards I realized, $DB::single is to be used as a bitmask.
So it would be 8 instead of 3, since 4 is already taken.
> >
> >> May I reserve the capital N for that command?
> > >
> > Nearly :-)
> >
> > I only mean you could use either 'nn' or 'N', equally. To be
> > honest, the former appeals a little more as an extention to the
> > existing command, while the latter seems to be a bit more distinct,
> > although I don't actually have another suggestion for the latter at
> > the moment either. If you implement it though, I suspect you can
> > use any letter you choose, certainly at first...
> >
>
> Hello,
>
> +1 on that. I like the idea of `nn' rather than 'N'. It's nicely in
> line with `-vvv' being ridiculously verbose in many GNU utils.
>
> Spiros Denaxas
Hmm, yes but it means more typing for what I consider my 'default'
(huffman coding, you know :-).
<heretic mode on>
From my experience with the debugger I would prefer the behaviour of
my proposal as a default for 'n'.
What would be the compatibility issue, if we change the behaviour of
'n' to what I proposed? Would something be missing?
Would you be annoyed by such a change? The only difference should be the
execution of grep/map/sort/...
I either use 's' to do small steps or use 'n' with the intention to do
bigger steps. But currently I cannot get this behaviour. It is not
exactly what is documented, but this is what my expectation is (silly
me).
<heretic mode off>
The behaviour of 'n' is a technical byproduct of the debugger loop, it
seems to me. Nowhere in the debugger source $DB::single is checked for
the value 2. Only bit 0 ( 0 or 1 ) is checked and manipulated on
entering a sub. So the granularity of 'n' is the natural one.
To implement the proposed behaviour, I think temporary breakpoints need
to be set.
Thanks for your feedback,
Heiko
Richard Foley
>
> To Richard:
> Afterwards I realized, $DB::single is to be used as a bitmask.
> So it would be 8 instead of 3, since 4 is already taken.
>
> The only difference should be the execution of grep/map/sort/...
>
> I either use 's' to do small steps or use 'n' with the intention to do
> bigger steps. But currently I cannot get this behaviour. It is not
> exactly what is documented, but this is what my expectation is (silly
> me).
> <heretic mode off>
>
If you mean:
1. n <- next step over everything (including grep/map/sort).
2. s <- step into everything (including grep/map/sort).
3. forget nn and N.
Then I would think this would be (mostly very) intuitive change, and the
behaviour (most) people would expect from the debugger, most of the time.
You'd have to check for unwarranted side effects of course, such that blocks
other than single-line grep, map and sort, remain unaffected, but otherwise
it seems to me to be a good idea.
he...@hexco.de
> If you mean:
>
> 1. n <- next step over everything (including grep/map/sort).
>
> 2. s <- step into everything (including grep/map/sort).
>
> 3. forget nn and N.
>
> Then I would think this would be (mostly very) intuitive change, and
> the behaviour (most) people would expect from the debugger, most of
> the time. You'd have to check for unwarranted side effects of
> course, such that blocks other than single-line grep, map and sort,
> remain unaffected, but otherwise it seems to me to be a good idea.
I forgot to mention, yes I agree.
My patch changed only 'n' like you wrote.
Heiko
--
Richard Foley
>
> > 1. n <- next step over everything (including grep/map/sort).
> >
> > 2. s <- step into everything (including grep/map/sort).
> >
>
> Ok, here is what I did, patch is against Perl 5.10.0.
> Please review, thanks. My simple tests worked so far.
>
From an initial look at it, it looks good to me, (and works nicely ;), too.
Just one thing, you might need to change the regex:
if ( $dbline[$line] =~ m{\bgrep\b}xms
|| $dbline[$line] =~ m{\bmap\b}xms
|| $dbline[$line] =~ m{\bsort\b}xms
) {
to handle join and reverse as well:
if ( $dbline[$line] =~ m{
\b(grep|join|map|reverse|sort)\b
}xms ) {
Maybe try a few single- and multi-line variations and, if it still looks good,
submit a proposed patch to p5p?
Richard Foley
>
> > \b(grep|join|map|reverse|sort)\b
>
> 'reverse'.
>
Ok.
> I also checked
> s expr
> and
> n expr
>
Good to hear :-)
> BTW:
> with the definition
> sub x1 {
> my $arg = shift;
> return reverse unpack "(a)*", $arg; }
>
> if I single step through an expression
> like this
> s @x = x1('blabla')
> s
> s
> ...
> (up to the end of function x1)
> I never see the returned result. Neither in the debugger output,
> nor in the variable @x. That is, when I do afterwards
> x \@x
> the array is empty.?!?!?
> (ok, I just see, it is not empty, if @x has been used before,
> what a weird behaviour, what is going on??? :-)
>
Maybe it's a localisation issue?
Heiko
> Just one thing, you might need to change the regex:
>
> if ( $dbline[$line] =~ m{\bgrep\b}xms
> || $dbline[$line] =~ m{\bmap\b}xms
> || $dbline[$line] =~ m{\bsort\b}xms
> ) {
>
> to handle join and reverse as well:
>
> if ( $dbline[$line] =~ m{
> \b(grep|join|map|reverse|sort)\b
> }xms ) {
>
>
stepping 's' in the debugger.
Only the 'grep' and 'map' operators were always stopped for each array
element,
probably because you must specify a block or an expression.
For 'sort', it depends on the compare function. None, or explicitly the
default one are not interrupted,
if you supply your some other compare function, it will be interrupted.
'Join' and 'reverse' ran always in one step, probably because no code
blocks are involved.
The combination of 'reverse' and 'sort' behaves like a single 'sort'.
So I think I will take your proposal and will leave out 'join' and
'reverse'.
Or did I miss something?
> Maybe try a few single- and multi-line variations and, if it still looks good,
> submit a proposed patch to p5p?
>
Yes, I will do that. All is looking good.
I also checked
s expr
and
n expr
BTW:
with the definition
sub x1 {
my $arg = shift;
return reverse unpack "(a)*", $arg; }
if I single step through an expression
like this
s @x = x1('blabla')
s
s
...
(up to the end of function x1)
I never see the returned result. Neither in the debugger output,
nor in the variable @x. That is, when I do afterwards
x \@x
the array is empty.?!?!?
(ok, I just see, it is not empty, if @x has been used before,
what a weird behaviour, what is going on??? :-)
Greetings,
Heiko
he...@hexco.de
I discussed this topic and patch on PerlMonks, and got a general
agreement, that the patch would have great merit.
The Problem
===========
Then I discovered a corner case I don't handle well:
$c++; $d++; $e++; print 'map';
will not work as before with 'n'.
Suddenly I found the detection of map/grep/sort
with a regexp very weak and fragile. So I am not content yet.
The Idea
========
When I looked into the debugger source, it seemed to me then
(lightbulb on) that the special treatment of 'n' regarding
subroutines only needs to be extended to general code blocks
like those in grep/map/sort, and
like those in any/all/...
if you use List::Utils and List::MoreUtils.
Evidence
========
While experimenting I found that sort without a code block
was stepped over with a single 'n'!
When a code block was given, that was not the default one,
'n' stepped into each invocation of the code block and stopped.
Probably that is also the reason that join and reverse are stepped
over with a single 'n'. They don't have user supplied code blocks.
Seen that way the special treatment of 'n' was 'sort of' incomplete
because it shortcutted only code blocks of explicitly declared
subroutines.
New Plan
========
So I would like to make a patch now, that will have 'n' short cut for
ANY code block, not only subroutines. And that should be done without a
regexp.
Help is of course very much appreciated!!
What do you think?
Geetings,
Heiko
Richard Foley
> Hello Richard,
>
> I discussed this topic and patch on PerlMonks, and got a general
> agreement, that the patch would have great merit.
>
Good to hear that - I found the thread and appended my half'pen'th.
> New Plan
> ========
> So I would like to make a patch now, that will have 'n' short cut for
> ANY code block, not only subroutines. And that should be done without a
> regexp.
>
Hmmm, yes but there's always exceptions... consider arriving at the following
pseudocode under the debugger:
<DB 1>
{
code1;
code2;
code3;
}
code4;
Do you want to step over all the three code lines above with 'n'? Probably
not if it's just a way of controlling lexical variables, for example, you
would be expecting to step to the next statement (code1) rather than leap
over to code4. I'm not sure what the solution is, but as you can see from the
various comments, it's never quite as simple as it might seem at first.
Possibly because it's Perl, there's just SMWTDI (so many ways to do it), that
these kind of edge cases can become quite problematic.
> the special treatment of 'n' regarding subroutines only needs to be extended
> to general code blocks like those in grep/map/sort, ...
>
It's perl which provides the hook for the debugger, calling DB::sub on each
subroutine, just as DB::DB gets called for each line, so I'm not sure how
easy it's going to be to extend that handling for map{} and grep{} and sort{}
blocks, unless you modify Perl's source too. You may still have to emulate
it in the way you started to...
> Help is of course very much appreciated!!
>
If I can help, I'll be happy to do so.
he...@hexco.de
Richard Foley wrote:
> > New Plan
> > ========
> > So I would like to make a patch now, that will have 'n' short cut
> > for ANY code block, not only subroutines. And that should be done
> > without a regexp.
> >
> Hmmm, yes but there's always exceptions... consider arriving at the
> following pseudocode under the debugger:
>
> <DB 1>
> {
> code1;
> code2;
> code3;
> }
> code4;
>
> Do you want to step over all the three code lines above with 'n'?
No, I don't want that. I probably phrased my intention unprecisely.
Whenever a real subroutine is involved, it should be stepped over.
Sometimes this is an argument to the sort function...
> Probably not if it's just a way of controlling lexical variables, for
> example, you would be expecting to step to the next statement (code1)
> rather than leap over to code4. I'm not sure what the solution is,
> but as you can see from the various comments, it's never quite as
> simple as it might seem at first. Possibly because it's Perl,
> there's just SMWTDI (so many ways to do it), that these kind of edge
> cases can become quite problematic.
Agreed.
Heiko