Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

•Re^3: No Pause on Elsif in Debugger

by merlyn (Sage)
on Jul 23, 2004 at 16:10 UTC ( #376914=note: print w/replies, xml ) Need Help??

in reply to Re^2: No Pause on Elsif in Debugger
in thread No Pause on Elsif in Debugger

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.

Replies are listed 'Best First'.
Re^4: No Pause on Elsif in Debugger
by QM (Parson) on Jul 23, 2004 at 19:13 UTC
    Any chance of getting a nice little discussion about this decision, or a point to the design discussion? The historian in me is looking for new material.

    There are only 11 people in the world. Those who understand unary, and those who don't.

      My somewhat wild conjecture is that this is related to how line numbers are reported incorrectly for elsif code (the number of the line of the if is reported instead).

      The broken line numbering is clearly a bug and justifies more effort be marshaled to fix it than the debugger issue.

      Further, I conjecture that both are somewhat affected by the Perl4 optimization where a suitable if/elsif/else chain is converted into an efficient 'switch statement' (computed goto).

      - tye        

        Further research...given this:
        #!/your/perl/here use strict; use warnings; my $rand = rand; if ( $rand < rand ) { print "if1: $rand\n"; } elsif ( $rand < rand ) { print "elsif2: $rand\n"; } else { print "else3: $rand\n"; }
        works fine. Changing line 11 to:
        elsif ( ( $rand < rand ) { print "elsif2: $rand\n"; }
        gives the error:
        syntax error at C:\ line 12, near ") {"
        But using this version instead:
        elsif ( $rand < _rand ) { print "elsif2: $rand\n"; }
        gives the compile error:
        Bareword "_rand" not allowed while "strict subs" in use at C:\if_elsif line 7.
        Given that you can chain elsifs together indefinitely, it is possible to cause an error at any line after line 7, but still be pointed to line 7.

        You may be wondering what happens if use strict is turned off - it just generates a warning instead:

        Argument "_rand" isn't numeric in numeric lt (<) at C:\Perl\perlmonks\ line 7.
        Turning off warnings then doesn't complain. I was unable to generate a message that pointed to some line besides the line of the actual error +/-1. Only turning on strict and warnings caused misleading messages.

        So it appears (from minimial empirical evidence) that syntax errors generate mostly correct line numbers, but strict and warnings do not, probably because information about the structure of the if/elsif/else has been removed from the [insert appropriate entity name here]

        However, if another if/elsif/else is nested in one of the if blocks, it's if entry point is retained (but it's elsif/else info is not).

        The remaining question I have is:

        What information is thrown out, and at what stage of the compilation/execution?
        [The original question, "Why doesn't the debugger pause on elsif conditionals?", seems to hinge on the answer to this new question.]

        Quantum Mechanics: The dreams stuff is made of

      I'm no expert on this but I goaded a few experts on this and in the end I don't think they came up with any good reasons why 'elsif' shouldn't just be declared "a statement" as far as opcode generation is concerned so that run-time line numbers can be correct and the debugger can stop on such lines.

      I expected that this would find its way to p5p and someone would post some evidence of that to this thread. Maybe this goading will make that happen. If not, you might want to escalate to p5p yourself (after first searching the archive to see if it has already been discussed).

      - tye        

        This involves making the optimizer optimize less for a case that it already did well enough in. This new optimize-by-doing-less would only be appropriate during -d debugging and then might be considered a source of heisenbugs.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://376914]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2017-11-21 03:30 GMT
Find Nodes?
    Voting Booth?
    In order to be able to say "I know Perl", you must have:

    Results (295 votes). Check out past polls.