Step-by-step debugging does not work for if elsif elsif

[p5pRT]

Migrated from rt.perl.org#132653 (status was 'open')

Searchable as RT132653$

[p5pRT]

From @KES777

Very often in the program there are consecutive ifs. Like this​:

$x = <>;

if( !$x ) {
  print 1;
}
elsif( $x eq 'asdf' ) {
  print 2;
}
elsif( $x ne 'asdf' ) {
  print 3;
}
else {
  print 4;
}

And this is unhandy when 's' debugger command skip all ifs and do not stop on each.
For example 'elsif' is skipped on line 8​:

$ perl -d ./t.pl

Loading DB routines from perl5db.pl version 1.49_04
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main​::(./t.pl​:3)​: $x = <>;
  DB<1> s
df
main​::(./t.pl​:5)​: if( !$x ) {
  DB<1> s
main​::(./t.pl​:12)​: print 3;
  DB<1>

expected debugging​:

main​::(./t.pl​:3)​: $x = <>;
  DB<1> s
df
main​::(./t.pl​:5)​: if( !$x ) {
  DB<1> s
main​::(./t.pl​:8)​: elsif( $x eq 'asdf' ) {
  DB<1> s
main​::(./t.pl​:12)​: print 3;
  DB<1>

[p5pRT]

From @iabyn

On Mon, Dec 25, 2017 at 01​:19​:59AM -0800, KES wrote​:

# New Ticket Created by KES
# Please include the string​: [perl #132653]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132653 >

Very often in the program there are consecutive ifs. Like this​:

$x = <>;

if( !$x ) {
print 1;
}
elsif( $x eq 'asdf' ) {
print 2;
}
elsif( $x ne 'asdf' ) {
print 3;
}
else {
print 4;
}

And this is unhandy when 's' debugger command skip all ifs and do not stop on each.
For example 'elsif' is skipped on line 8​:

$ perl -d ./t.pl

Loading DB routines from perl5db.pl version 1.49_04
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main​::(./t.pl​:3)​: $x = <>;
DB<1> s
df
main​::(./t.pl​:5)​: if( !$x ) {
DB<1> s
main​::(./t.pl​:12)​: print 3;
DB<1>

expected debugging​:

main​::(./t.pl​:3)​: $x = <>;
DB<1> s
df
main​::(./t.pl​:5)​: if( !$x ) {
DB<1> s
main​::(./t.pl​:8)​: elsif( $x eq 'asdf' ) {
DB<1> s
main​::(./t.pl​:12)​: print 3;
DB<1>

's' is documented as​:

  Single step. Executes until the beginning of another
  statement

Perl compiles if/else chains into ?​: expressions; for example,

  if (C1) {
  S1;
  } elsif (C2) {
  S2;
  } elsif (C3) {
  S3;
  } else {
  S4;
  }

gets compiled to the equivalent of​:

  C1 ? do { S1; } : C2 ? do { S2; } : C3 ? do { S3 } : do { S4 };

which the debugger sees as a single expression.

--
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
  -- Woody Allen

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @xsawyerx

Determined not a bug. Rejecting ticket.

[p5pRT]

@xsawyerx - Status changed from 'open' to 'rejected'

[p5pRT]

From @KES777

C1 ? do { S1; } : C2 ? do { S2; } : C3 ? do { S3 } : do { S4 };
which the debugger sees as a single expression.

Hope this will someday be seen by debugger as a few expressions

[p5pRT]

From @eserte

"Sawyer X via RT" <perlbug-followup@​perl.org> writes​:

Determined not a bug. Rejecting ticket.

IMHO this issue is valid. The current behavior represents bad user
experience. Perl's internal representation is irrelevant here.

Regards,
  Slaven

--
Slaven Rezic - slaven <at> rezic <dot> de

  Berlin Perl Mongers - http​://berlin.pm.org

[p5pRT]

From @xsawyerx

On Thu, 28 Dec 2017 06​:14​:55 -0800, slaven@​rezic.de wrote​:

"Sawyer X via RT" <perlbug-followup@​perl.org> writes​:

Determined not a bug. Rejecting ticket.

IMHO this issue is valid. The current behavior represents bad user
experience. Perl's internal representation is irrelevant here.

This can be a wishlist item for the debugger, but it is not a bug with the language. It is just the way the language is.

I'm not sure it's possible to accomplish, though. Dave, what do you think?

[p5pRT]

From @eserte

"Sawyer X via RT" <perlbug-followup@​perl.org> writes​:

On Thu, 28 Dec 2017 06​:14​:55 -0800, slaven@​rezic.de wrote​:

"Sawyer X via RT" <perlbug-followup@​perl.org> writes​:

Determined not a bug. Rejecting ticket.

IMHO this issue is valid. The current behavior represents bad user
experience. Perl's internal representation is irrelevant here.

This can be a wishlist item for the debugger, but it is not a bug with the language. It is just the way the language is.

Whether it's called a bug, a problem, an issue or a wishlist item ---
it's a something which should be addressed, and documented. If it's
unfixable or too impractical to fix --- there's a "BUGS" section in
perldebug.pod (or it could go into a new "LIMITATIONS" section). If it's
fixable, but requires considerable effort, then it could go to todo.pod.

At least this something deserves a little bit of discussion.

Regards,
  Slaven

--
Slaven Rezic - slaven <at> rezic <dot> de
  BBBike - route planner for cyclists in Berlin
  WWW version​: http​://www.bbbike.de
  Perl/Tk version for Unix and Windows​: http​://bbbike.sourceforge.net

[p5pRT]

From @jkeenan

Re-opening and classifying ticket as Wishlist. For the time being, a documentation patch describing the limitation would be welcome.

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

@jkeenan - Status changed from 'rejected' to 'open'

[p5pRT]

From @xsawyerx

On Thu, 28 Dec 2017 14​:49​:27 -0800, jkeenan wrote​:

Re-opening and classifying ticket as Wishlist. For the time being, a
documentation patch describing the limitation would be welcome.

Thank you. I just opened the ticket to do the same, following Slaven's comments.

[p5pRT]

From @iabyn

On Thu, Dec 28, 2017 at 04​:31​:58PM +0100, Slaven Rezic wrote​:

Whether it's called a bug, a problem, an issue or a wishlist item ---
it's a something which should be addressed, and documented. If it's
unfixable or too impractical to fix --- there's a "BUGS" section in
perldebug.pod (or it could go into a new "LIMITATIONS" section). If it's
fixable, but requires considerable effort, then it could go to todo.pod.

At least this something deserves a little bit of discussion.

My opinions​:

1) It's not a bug, in that its behaving exactly as documented;
2) but it would be nice to have better behaviour;
3) but it would probably be hard to achieve that behaviour;
4) I'm not opposed to the documentation for the 's' command in the
debugger to be improved to clarify what's meant by 'the next statement'
(but I'm not volunteering to do it myself).

--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"