Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

How to use Plack InteractiveDebugger

by jjmoka (Beadle)
on Jun 19, 2015 at 08:20 UTC ( #1131113=perlquestion: print w/replies, xml ) Need Help??

jjmoka has asked for the wisdom of the Perl Monks concerning the following question:

Did any wise monk used Plack InteractiveDebugger ? Where I can find how to use what I'd expect it's inside there (breakpoints, next, step, watch vars and the like) ?

Replies are listed 'Best First'.
Re: How to use Plack InteractiveDebugger
by Anonymous Monk on Jun 19, 2015 at 10:04 UTC
Re: How to use Plack InteractiveDebugger
by sundialsvc4 (Abbot) on Jun 19, 2015 at 11:28 UTC

    Okay, let me put my name on the following suggestions, and try my best to make them positive ones:

    Yes, there are debuggers for Plack, as for every other type of [Perl ...] application, but I have generally found them to be of limited usefulness.   In fact, I rarely use debuggers at all.   Plack (PSGI) applications are actually much easier to debug in general, e.g. compared to mod_perl, because you can cleanly separate them from the environment in which they are normally run, and instead run them in a functionally-equivalent environment that is much easier to debug.

    In the case of Plack, that would start with the plackup command, but also with quite a number of prove-compatible testing frameworks.   A compatible HTTP server runs right at your own command-line, or within the test framework.   Or, a tester simply sends a request-object to your script and evaluates the response-object that it returns.   Unlike mod_perl, PSGI applications are not embedded into their environment, but are simply call-and-response remote procedure call (RPC) handlers who run a certain number of requests until they commit hara-kiri and are promptly reborn.

    Not to get into any hint of mod_perl bashing, I have re-engineered several “embedded apps” to instead use the PSGI technique (and not just in the Perl language), and each time found that debugging became very simple and that some fairly intractable bugs were found almost immediately after the conversion.

    For most debugging purposes, I simply do a lot of print STDERR calls, which show-up right at my terminal window while running plackup on the command line.   I then accompany that with some very-conventional (prove ...) test suites to thoroughly exercise the code in order to flush out the more subtle problems.

      Ok, thanks to all!! I somehow misunderstood the meaning of that tool, but  InteractiveDebugger sounds thus pretty an unhappy name. I have a real massive bunch of CGI code to investigate and frankly printing\dumping\call-stacking in error_log, or logging through Log::Log4perl still let me miss a real debugging experience. I tried komodo-like EPIC plugin, and I stopped looking at Apache::DB/mod_perl as I was debugging most of the time Registry code instead of my own. Trying to make Apache::DBexperience working better I read of PSGI/Debugger and all the rest and I moved on that. Now I realize it's a some better stack trace improvement but far away from what a real debugging should be. "Real Programmers don't need debuggers, they can read core dumps. Larry Wall" .... ok maybe. I can still use the bicycle to make 2000 miles, but when the others use planes out there some doubts arise

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1131113]
Approved by kcott
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2023-11-28 13:00 GMT
Find Nodes?
    Voting Booth?

    No recent polls found