Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Step-by-step debugging do not work for if elsif elsif #16341

Closed
p5pRT opened this issue Dec 25, 2017 · 13 comments
Closed

Step-by-step debugging do not work for if elsif elsif #16341

p5pRT opened this issue Dec 25, 2017 · 13 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Dec 25, 2017

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

Searchable as RT132653$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 25, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

From @xsawyerx

Determined not a bug. Rejecting ticket.

@p5pRT p5pRT closed this Dec 28, 2017
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 28, 2017

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 29, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 2, 2018

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.