Re: accelerated stepping
Hi Richard,
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:
>
>
> {
> 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
Re: accelerated stepping
On Thursday 04 September 2008 21:33:41 Heiko Ei�feldt wrote:
> Hello Richard,
>
> I discussed this topic and patch on PerlMonks, and got a general
> agreement, that the patch would have great merit.
>
Hi Heiko,
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:
{
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.
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
Re: accelerated stepping
Hello Richard, 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
Re: accelerated stepping
Richard Foley schrieb:
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 ) {
I tested 'grep', 'map', 'sort', 'join', and 'reverse' with single
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 [EMAIL PROTECTED]
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
Re: accelerated stepping
On Monday 01 September 2008 22:50:53 Heiko wrote:
>
> > \b(grep|join|map|reverse|sort)\b
>
> So I think I will take your proposal and will leave out 'join' and
> '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 [EMAIL PROTECTED]
> 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?
--
Richard Foley
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
Re: accelerated stepping
On Saturday 30 August 2008 22:21:34 Heiko Ei�feldt wrote:
>
> > 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
Ciao - shorter than aufwiedersehen
http://www.rfi.net/
Re: accelerated stepping
Richard Foley wrote: > 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 --
Re: accelerated stepping
Richard Foley wrote: > On Friday 29 August 2008 19:28:08 Heiko Eifeldt wrote: > > > > 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. > > > Details, details ;-) > > > 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). > > > > > 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. Ok, here is what I did, patch is against Perl 5.10.0. Please review, thanks. My simple tests worked so far. Greetings, Heiko -- accelerated_n_perldb.pl.diff Description: Binary data
Re: accelerated stepping
On Friday 29 August 2008 19:28:08 Heiko Ei�feldt wrote: > > 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. > Details, details ;-) > 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). > > 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. -- Richard Foley Ciao - shorter than aufwiedersehen http://www.rfi.net/
Re: accelerated stepping
"Spiros Denaxas" wrote: > On Fri, Aug 29, 2008 at 3:53 PM, Richard Foley > <[EMAIL PROTECTED]> 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 :-). >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). 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
Re: accelerated stepping
On Fri, Aug 29, 2008 at 3:53 PM, Richard Foley <[EMAIL PROTECTED]> wrote:
> Hi Heiko,
>
>> 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...
>
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
> --
> Richard Foley
> Ciao - shorter than aufwiedersehen
>
> http://www.rfi.net/
>
> On Wednesday 27 August 2008 21:33:25 Heiko EiÃfeldt wrote:
>> Hi,
>>
>> 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
>> --
>>
>
Re: accelerated stepping
Hi Heiko,
> 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
http://www.rfi.net/
On Wednesday 27 August 2008 21:33:25 Heiko EiÃfeldt wrote:
> Hi,
>
> 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
> --
>
