> Am 26.10.2014 um 16:17 schrieb Derick Rethans <der...@php.net>: > > 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.
That’s definitely your mistake. I also don’t remember that you seriously commented about the original RFC. >> 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? I agree, that was a bad argument. That was just in comparison to phpng which was developed completely closed-source. >> 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. It wasn’t my idea. It was requested. There are issues on more than one bugtracker about phpdbg inclusion in the IDE. See, people want it. So, I just give them the underlying mechanisms so that they can use it inside their favorite IDE. >> 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. It still doesn’t. The IDE will handle it for you. (IDE creates a ssh connection and starts the phpdbg process - you don’t have to do anything.) >> - 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. Sorry, but I had the impression you weren’t cooperative with anyone. That’s why I didn’t approach you and try to discuss friendly. > cheers, > Derick > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
