phpdbg

phpdbg.txt

>  It's just terrible to use the opcodes could be hidden, maybe toggle with a verbosity level flag e.g -v2. 

They are hidden by default, you are shown opcodes when it's appropriate to show you opcodes or on request, if there's a bug, please report it.

> It's not smooth like pdb in python - having to 'eval' everything doesnt feel right.

You appear to be complaining that this isn't like some other software you have used, I'm not sure what to do with that.

Having to eval everything makes sense from the perspective that not all input is code, this is not a REPL, this is a debugger. What for example do we do with the input "run" if there is a run constant defined !? The answer is; nothing that makes sense in all situations. What does make sense, is eval'ing code.

> There's WAAAAAY too much being targetted, strip it back to be focused on debugging code not debugging ZEND, if you want to debug zend using the same software then im not opposed but it should be hidden by default.

If you're not opposed to it, then why are you opposing it !? You can simply ignore things you don't need to use.

> http://phpdbg.com/static/phpdbg.png

This is out of date, use the "help" command to get help, I should have updated the screenshot, but more pressing matters at hand.

> This feels more focussed and applicable to what common developers need. Again I sympthasise that the objectives are to debug 'anything' php... but it's too much to expose and for people to take on board with 5.6.

Again, ignore what you don't need or don't feel the need to understand.

> There are other niggly bits I found like readline not working properly, I had compiled php with readline and phpdbg still doesn't work like I'd expect (up/down arrows etc). 

You will find in the issues list some problems related to linking with readline, it sounds like readline link is broken after all phpdbg doesn't do anything to invoke that functionality, it is present if readline is linked correctly. If you can reproduce this with the latest sources, please do open a bug up.

phpdbg was voted in 40:0, it's safe and sensible to assume that the majority of those internals developers that voted it in did build and run phpdbg before they voted. Havng been included in a beta release is the very very first step for this software.

The readline problem aside, you haven't said anything that leads me to believe it's not ready for release. 5.6 is still in beta, we have been working throughout RC's to improve and debug. phpdbg is by necessity beta software right now, it's largely untested with a very large audience, as the 5.6 series progresses the software will improve, just like 5.6.

We are in touch with the phpstorm team, we do intend to implement a more robust form of remote debugging, but this was not a concern at first.

We have no wish for phpdbg do be the "defacto" debugger, there is no defacto anything. xdebug is perfectly mature software, I fully expect that hardly anyone will change their workflow to incorporate phpdbg at this point in it's development. It would not be sensible right now, just like it wouldn't be sensible to deploy 5.6 right now.

Essentially you are complaining that beta software is beta software.