Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

No Pause on Elsif in Debugger

by QM (Vicar)
on Jul 22, 2004 at 21:55 UTC ( #376737=perlquestion: print w/ replies, xml ) Need Help??
QM has asked for the wisdom of the Perl Monks concerning the following question:

I've noticed recently that the debugger doesn't pause on elsifs, making it confusing to follow sometimes.

For instance, given this code:

#!/your/perl/here use strict; use warnings; my $rand = rand; if ( $rand < rand ) # 1 { print "if 1: $rand\n"; } elsif ( $rand < rand ) # 2 { print "elsif 2: $rand\n"; } elsif ( $rand < rand ) # 3 { print "elsif 3: $rand\n"; } else { print "else 4: $rand\n"; }
I get the following in a debugger session:
C:\Perl\perl\perlmonks>perl -d skip_elsif.pl Loading DB routines from perl5db.pl version 1.19 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(skip_elsif.pl:6): my $rand = rand; DB<1> s main::(skip_elsif.pl:8): if ( $rand < rand ) # 1 main::(skip_elsif.pl:9): { DB<1> p $rand 0.63232421875 DB<2> main::(skip_elsif.pl:22): print "else 4: $rand\n"; DB<2> else 4: 0.63232421875
I'm expecting the debugger to pause on each conditional, especially as I might want to inspect some of the variables before the next evaluation. [I wouldn't mind if it paused on elses also, but I supposed that's too much to ask?]

Why does it work this way?

-QM
--
Quantum Mechanics: The dreams stuff is made of

Comment on No Pause on Elsif in Debugger
Select or Download Code
•Re: No Pause on Elsif in Debugger
by merlyn (Sage) on Jul 22, 2004 at 22:47 UTC
      It "pauses" on the beginning of a statement. elsif is not the beginning of a statement.
      Is that DWIM? What behavior do we want?

      I expect that it will at least pause on the evaluation of interesting conditionals [elsif (0) being an example of an uninteresting one]

      -QM
      --
      Quantum Mechanics: The dreams stuff is made of

        It doesn't really matter if that's exactly what you want. It would take a major overhaul (major) of the interface between the execution engine and the debugger Perl code to get it to do anything else. It's a very fundamental design choice. It's just like you can't set a breakpoint to see the "middle" of a map operation, other than at a statement boundary in a called subroutine.

        The debugger gets notified only as each statement is entered. That's it.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

        Of course, the Right Place to put the breakpoints is on the code *inside* the if/elsif/else - "right" being "you will actually stop somewhere near where you want to be". I've noticed similar annoying behavior with for loops at times. Just set your breakpoints inside and the problem goes away. This is the least intrusive solution; obviously, you can code to the debugger's limitations by doing things like
        if ($cond1) { ... } else { if ($cond2) { ... } else { if ($cond3) { .. } } }
        and now you can break at every if. (That looks scarily like some of my old PL/1 programs...)
Re: No Pause on Elsif in Debugger
by qq (Hermit) on Jul 22, 2004 at 22:48 UTC

    Update: missed the point.

    Its just following the control flow. Its not going to evaluate elsifs that it doesn't need to, because a prior condition passed. I think the rands in your statements are obscuring the issue.

    if ( 1 ) { # debugger will see this, just like code } elsif ( 1 ) { # won't see this - nothing will } else { # nor this either }

    qq

      Um, you're missing something, too. Take the code:
      if ( 0 ) { warn "a"; } elsif (1) { warn "b"; } else { warn "c"; }
      You will see this execution:
      main::(/tmp/foo:12): if ( 0 ) { DB<1> n main::(/tmp/foo:15): warn "b"; DB<1> n b at /tmp/foo line 15.
      So in an elsif chain, you always see just the first condition, not the first matching condition as your post states.

      20040725 Edit by ysth: correct <code> to </code>

      Attention: Could it not be that the optimizer simply "optimizes away" the code it can never reach? This would not happen with the "rand" statements.

      Anyhow it doen't matter as far as the debugger is concerned: the debugger only stops on "if"-part.

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: No Pause on Elsif in Debugger
by CountZero (Bishop) on Jul 23, 2004 at 15:02 UTC
    I checked it in the graphical debugger of KOMODO and it stops only on the first "if" statement and then goes on to the statements after the "elseif", never stopping on these "elseif".

    Even if you put a "breakpoint" on an "elseif", the debugger stops on the first "if".

    It seems the whole of the "if -elseif - else" construct is indeed considered "one"

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://376737]
Approved by NetWallah
Front-paged by NetWallah
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (4)
As of 2014-07-24 04:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (157 votes), past polls