Re: PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)

On Sat, 25 Oct 2014, Weinand Bob wrote: > Just a minor question, Derick. If you care about phpdbg, why are you > only dropping any comment about it by the time it got into php-src > repo? Yes, my mistake. I should have voted -1, but as I thought there was a conflict of interest, I stayed silent. > It’s known that all the development currently (except for > master, but that just was a merge and then a pure rewrite on top of > that merge, nothing related to the protocol) is going on in > krakjoe/phpdbg github repo. There was now an xml-protocol branch for > three weeks before it got merged into krakjoe/phpdbg#master. You had > vast time to notice it and complain before, if you’d really have > cared. Sorry, but do you really expect people to follow some random person's github repo+branch for something that gets source-dumped into php-src? > To reply to your question: why not use another debugger protocol? I > had first really looked for other protocols, but none really fitted > our needs. There was just DBGp which approximated our needs. > At the beginning I had tried to implement a slightly modified variant > of DBGp, but it accumulated minor differences here and there… And that > then doesn’t make much sense again. Indeed - it's after all a documented protocol. > That was the time where we decided to implement our own protocol. I don't even see *why* you want to write a whole new remote debugger in the first place. > Before you ask, an incomplete list of such differences: > > - connecting: phpdbg is the server, not the client (as opposed to what > DBGp requires) And for good reasons... as it doesn't require people to do fiddly command line stuff to debug multiple requests. > - no need for the proxy thing > - breakpoints: we have an opline-wise breaking (I have no idea, but > maybe an IDE might want to break before the fcall is done) doesn’t > fit into current list of attributes > - It is under some circumstances possible to not be able to provide a > full response (e.g. we’ve done a hard interrupt (that means, instant, > asynchronous interrupt, even when engine is in control of it)) - > DBGp provides no mechanism to handle it > - stdout, stderr commands also don’t really work with phpdbg — it’s always redirect mode These three points are valid, but then there is (probably) also no reason why it couldn't be added. And there is also no requirement for stdout/stderr to be implemented. cheers, Derick