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

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? 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. 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. That was the time where we decided to implement our own protocol. Before you ask, an incomplete list of such differences: - connecting: phpdbg is the server, not the client (as opposed to what DBGp requires) - 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 - … Further, but not the main reason why we didn’t use it, we’d have had to implement another commands lexer, parser and interpreter alongside our current commands. DBGp commands aren’t exactly user-friendly; they’re designed to be used by a machine. It made the whole implementation a lot easier to not use a fork of DBGp adapted to our needs. (at the time we realized we couldn’t really use DBGp) So, we’ve introduced a new protocol. I didn’t try to make a protocol compatible with any future debugger; each debugger has a bit his special needs and you cannot suit everyones needs. Bob p.s.: And yes, PhpStorm was involved, a huge thanks to them for the precious feedback they’ve given me for the last three weeks. > Am 25.10.2014 um 11:45 schrieb Pierre Joye <pierre.php@gmail.com>: > > On Sat, Oct 25, 2014 at 4:39 PM, Joe Watkins <pthreads@pthreads.org> wrote: > >> Pierre, >> >> I wasn't involved in the conversations during it's development very >> much. You will have to wait for bob or someone from the phpstorm team to >> fill in the blanks. Suffice to say that they found a reason to work on a >> new protocol, details I don't know. >> >> It had it's own remote protocol when it was merged, but it turned out >> to be pretty useless for those people interested in using it remotely. >> >> This is only a development of that original feature. >> >> I of course recognize that we are in some sense representative of the >> PHP project, however, we are talking about words like awesomesauce, not >> profanity, or anything offensive whatever. >> >> Bob done all the work on this, in record time. It's totally crappy that >> he'll wake up today to this nonsense, he should be feeling pleased with >> himself. He worked very hard on it. > > Cannot agree more. I very much like phpdbg and really appreciate all > the aweome work you guys have put in it. I am only trying to > understand this whole protocol thing, in the most objecitve way :). I > did not know phpstorm was involved either, that makes me feel better > about it. They know very well what is needed and have a very large > experience in this area. I am convinced things will be clear soon :) > > -- > Pierre > > @pierrejoye | http://www.libgd.org