Re: RFC: phpdbg

From: Date: Thu, 21 Nov 2013 17:19:15 +0000
Subject: Re: RFC: phpdbg
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-70265@lists.php.net to get a copy of this message
On 21/11/13 14:43, Michael Wallner wrote:
On 21 November 2013 15:38, Joe Watkins <krakjoe@php.net> wrote:
On 11/21/2013 02:20 PM, Nikita Popov wrote:
I'm probably missing some context here, maybe you could explain how phpdbg differs from something like xdebug? I mean, xdebug seems to be the de-facto debugging extension for PHP and has been for a long time, but we're not bundling it. Why should we bundle phpdbg instead?
         This is not an extension, it is a SAPI module. The build system does
not support external SAPI modules, the implementation requires Zend API which is not exported (or wasn't, has since been patched).
That still does not answer the question, though?! Nikita asked *two* questions. Joe answered the first. My reading of what he says, plus following the links to his write up on http://phpdbg.com, is because phpdbg is a SAPI -- as far as I can see esentially a debug variant of the CLI SAPI -- you can use it very much the same way that you can debug perl scripts with the "perl -d" switch.
This is functionality that I for one REALLY miss with PHP. Maybe its just me, but I've tried using xdebug without modifying the source, and I find it very difficult to configure for anything other than getting smart tracebacks on errors. Also xdebug being an extension, you have to be careful about load order when debugging other extensions. I usually give up using xdebug and add (temporary) diagnostics to the PHP source code. As to Nikita's second Q: why should we bundle phpdbg instead of xdebug? I think that an average PHP developer would find a CLI debug interface that could be enabled through a command line switch a valuable addition to the PHP development toolset. This utility argument was valid for the -S option and the CLI webserver mode, so why not apply this same argument here?

« previous php.internals (#70265) next »