Re: RFC: phpdbg

On 11/22/2013 08:07 PM, Philip Sturgeon wrote:

It definitely seems the PHPDBG site and RFC both need work to explain the purpose of this tool to a larger audience than the select few who are currently excited about it, and I have offered to help get that sorted out over the next few days. (Thanks for reaching out Joe). The first issue seems to be "Why not just use XDebug". Sure, these are both for debugging but XDebug works in a very different way. For starters xdebug is meant to "latch on" to the existing engine and provide debugging information and breakpoints for analysis. It also provides remote config tools for sending those breakpoint responses to another server so you can have a nice shiny Mac GUI working with a remote SSH server. That is all lovely, but not what this tool is trying to do - which is provide a new SAPI to run your code through for debugging. From the ground up it is built and designed to do this, instead of hooking into other bits of another engine. XDebug allows you to run your code through Apache/Nginx and get this data back, PHPDBG asks you to run your code through a different SAPI which can get you the same data but in a much more efficient and internally less complicated way. So which should people use? Probably both. Should they both exist? Certainly. Which should be merged into the core? The one designed as a SAPI and not as a module. Not 100% sure what you'd use PHPDBG for? Even if you do not use it yourself it could be used by frameworks like Laravel/Symfony to create awesome console servers, REPLs, etc that are considerably more powerful than the tools currently available due to limitations in the existing SAPs. If you try creating a REPL in pure PHP right now you're going to cry, but PHPDBG would make that easier. All in all, having this SAPI distributed to all PHP developers wether they like it or not (or wether they know what it is or not) is hugely beneficial - and has no BC issues whatsoever. Also by keeping XDebug as a module which has to be intentionally installed by people that want it, there is the hopeful chance that people will continue to avoid accidentally installing it into production - which is bad for a bevy of reasons. http://nikic.github.io/2012/01/19/Careful-XDebug-can-skew-your-performance-numbers.html http://stackoverflow.com/questions/3522182/will-enabling-xdebug-on-a-production-server-make-php-slower On Fri, Nov 22, 2013 at 2:40 PM, Andrea Faulds <ajf@ajf.me> wrote:

On 22/11/13 08:44, Ivan Enderlin @ Hoa wrote:

And please, with all my respect and without considering xdebug here, stop using the “de-facto [standard]” expression. A tool is not good because it is the only one to be in the place :-).

Nothing wrong with saying it's the de facto standard. It is the de facto standard, though that doesn't make it good. Maybe that's what you meant. Anyhow, I'd love for phpdbg to be included in PHP. Along with the CLI server, it'd make PHP a lot more developer-friendly :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Morning internals, I guess we are all busy on different things, more information will no doubt be coming to the RFC ... while that happens I thought I would provide a bit of an update. https://wiki.php.net/rfc/phpdbg I put a bit more info on the RFC about what phpdbg actually is and what it does, and there's more to read on the site too. I guess there's not long before a feature freeze on 5.6, so would like to start getting some feedback on whether or not we are actually going to vote on this for 5.6 ... Cheers Joe