# PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...) - Thread: https://externals.io/message/78456 - Original archive: https://news-web.php.net/php.internals/78456 - Started by Joe Watkins on 2014-10-30T08:36:07+00:00 - Messages: 45 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/78456.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #78320 — Derick Rethans — 2014-10-25T03:06:40+00:00 URL: https://externals.io/message/78456#78320 > Commit: 2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 > Author: Bob Weinand Fri, 24 Oct 2014 19:29:50 +0200 > Parents: 53560ca06b333b71883269091f7d74c0a25e087b c03ac47bafd0ea55055a2f3d4de0bc6bb4d98d8d > Branches: master > > Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 > > Log: > Made phpdbg compatible with new engine > AM sapi/phpdbg/xml.md Although this patch does make it work with PHP 7, it also does do something absolutely different: it reinvents a wheel by coming up with a new XML protocol for debugging. So far I've been silent on PHPDBG, but seriously, is it really not possible to cooperate instead of reimplementating something that already exists? PHPDBG is difficult to use with its odd command line "commands". And then I haven't even spoken about the pretentious "awesomesauce" on http://phpdbg.com/ — a domain that's not even under the PHP group's control. cheers, Derick --- ## #78321 — Joe Watkins — 2014-10-25T06:13:56+00:00 URL: https://externals.io/message/78456#78321 · In reply to: #78320 > > > > […] > > > > […] > > Although this patch does make it work with PHP 7, it also does do > something absolutely different: it reinvents a wheel by coming up with a > new XML protocol for debugging. > > So far I've been silent on PHPDBG, but seriously, is it really not > possible to cooperate instead of reimplementating something that already > exists? PHPDBG is difficult to use with its odd command line "commands". > And then I haven't even spoken about the pretentious "awesomesauce" on > http://phpdbg.com/ — a domain that's not even under the PHP group's > control. > > cheers, > Derick Derick, A few weeks ago, I was at a conference where you told a room filled with hundreds of developers that phpdbg was no good, because you don't know how to use it. This is a strange sort of silence, and does not invite us to co-operate. When you invented dbgp there were other protocols in existence, not sure why we are expected to reuse a protocol. It so happens that the phpstorm guys working on integration seemed keen on something new. I don't see the problem in that. If the only reason it exists is for projects like phpstorm and they are actually going to put time into trying something new, then why the hell not. I'm not sure why it matters what kind of language we use on phpdbg.com, not sure why you think it should be under the control of the php group either. If you had wanted to co-operate, you could have spoken to me at that conference in person, or to any of us in IRC, on any day. You chose to do what pleased you. We should be allowed to do the same. Joe --- ## #78322 — Pierre Joye — 2014-10-25T09:19:37+00:00 URL: https://externals.io/message/78456#78322 · In reply to: #78321 hi, > > […] > > Derick, > > A few weeks ago, I was at a conference where you told a room filled > with hundreds of developers that phpdbg was no good, because you don't > know how to use it. > > This is a strange sort of silence, and does not invite us to > co-operate. Well, not well played but I do not think arguing back and forth about that will bring us anywhere. I will just skip any part of this discussion about this kind of things. > When you invented dbgp there were other protocols in existence, not > sure why we are expected to reuse a protocol. It so happens that the > phpstorm guys working on integration seemed keen on something new. I > don't see the problem in that. If the only reason it exists is for > projects like phpstorm and they are actually going to put time into > trying something new, then why the hell not. While you are right from a principle point of view, I do think it makes sense to implement something which is already a de facto standard in the PHP world, well supported by various tools, etc. If phpdbg would not be in core, I would not care much, as you said, it would then be an independent project and you can do whatever you wish. However it is not the case, phpdbg is in the core. Being in core means it does affect how our users will work, use it, etc. Design decisions like protocol used to work with external tools should be taken very carefully. Adding yet another one does not sound very good at a first glance. Do you mind to enlighten us about the advantages of this new protocol over the existing one? Or what are the limitations of the existing one which lead you to the creation of a phpdbg protocol? > I'm not sure why it matters what kind of language we use on phpdbg.com, > not sure why you think it should be under the control of the php group > either. Well, phpdbg is part of the core. As such it reflects what PHP is, does or says. I do not have a problem with anything I have seen on the project site but this is something to keep in mind. > If you had wanted to co-operate, you could have spoken to me at that > conference in person, or to any of us in IRC, on any day. You chose to > do what pleased you. > > We should be allowed to do the same. Yes and no, as I wrote earlier in this reply. Thanks for the great work and let try to sort that out :) Cheers, Pierre --- ## #78323 — Joe Watkins — 2014-10-25T09:39:23+00:00 URL: https://externals.io/message/78456#78323 · In reply to: #78322 > hi, > > > > > > […] > > Well, not well played but I do not think arguing back and forth about > that will bring us anywhere. I will just skip any part of this > discussion about this kind of things. > > > […] > > > While you are right from a principle point of view, I do think it > makes sense to implement something which is already a de facto > standard in the PHP world, well supported by various tools, etc. If > phpdbg would not be in core, I would not care much, as you said, it > would then be an independent project and you can do whatever you wish. > However it is not the case, phpdbg is in the core. Being in core means > it does affect how our users will work, use it, etc. Design decisions > like protocol used to work with external tools should be taken very > carefully. Adding yet another one does not sound very good at a first > glance. > Do you mind to enlighten us about the advantages of this new protocol > over the existing one? Or what are the limitations of the existing one > which lead you to the creation of a phpdbg protocol? > > > […] > > Well, phpdbg is part of the core. As such it reflects what PHP is, > does or says. I do not have a problem with anything I have seen on the > project site but this is something to keep in mind. > > […] > > Yes and no, as I wrote earlier in this reply. > > Thanks for the great work and let try to sort that out :) > > Cheers, > Pierre 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. Cheers Joe --- ## #78324 — Pierre Joye — 2014-10-25T09:45:11+00:00 URL: https://externals.io/message/78456#78324 · In reply to: #78323 > 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 --- ## #78325 — Weinand Bob — 2014-10-25T11:00:15+00:00 URL: https://externals.io/message/78456#78325 · In reply to: #78324 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 : > > > > > […] > > 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 --- ## #78326 — Leigh — 2014-10-25T11:25:32+00:00 URL: https://externals.io/message/78456#78326 · In reply to: #78325 > ... Thanks Bob. So my question is: Obviously the phpdbg requirements do not map to DBGp. However, can all of the requirements of DBGp be mapped to the phpdbg XML? Going forward does the XML protocol cover everything XDebug needs? Can we do "DBGp over XML"? --- ## #78327 — Bob Weinand — 2014-10-25T13:14:40+00:00 URL: https://externals.io/message/78456#78327 · In reply to: #78326 > Am 25.10.2014 um 13:25 schrieb Leigh : > > > > […] > > Thanks Bob. > > So my question is: Obviously the phpdbg requirements do not map to > DBGp. However, can all of the requirements of DBGp be mapped to the > phpdbg XML? > > Going forward does the XML protocol cover everything XDebug needs? Can > we do "DBGp over XML“? We currently also don’t provide e.g. exception breaks (because either no-one of us thought of it or found it useful). There may be already the minor problems in the other direction. But generally, one could (after adding connection overhead). Though I wouldn’t think of it as a good idea as it’ll break everything which doesn’t support phpdbg, but xdebug. But it wasn’t primarily intended to be forward compatible with other debuggers. Bob --- ## #78328 — Sebastian Bergmann — 2014-10-25T15:37:39+00:00 URL: https://externals.io/message/78456#78328 · In reply to: #78325 Am 25.10.2014 um 13:00 schrieb Weinand Bob: > It’s known that all the development currently is going on in > krakjoe/phpdbg github repo. Why is that, exactly? I find it weird that something that is shipped with official releases of PHP is not developed alongside the rest of PHP. --- ## #78329 — Weinand Bob — 2014-10-25T16:01:05+00:00 URL: https://externals.io/message/78456#78329 · In reply to: #78328 > Am 25.10.2014 um 17:37 schrieb Sebastian Bergmann : > > Am 25.10.2014 um 13:00 schrieb Weinand Bob: > > […] > > Why is that, exactly? I find it weird that something that is shipped > with official releases of PHP is not developed alongside the rest of > PHP. That’s because all the work originated in the krakjoe/phpdbg repo, even before it was pushed to php-src. Also, it contains code which makes it compatible with PHP 5.4+. If it’d be in the main repo, users with lower PHP versions couldn’t use it at all. By the way, phpdbg in PHP 7 isn’t handled by that repo anymore, it’s directly in master. But new features will still have to be merged up (except if it are PHP 7-only features) as long as PHP 5 branch has still one active (non-sec-fixes-only) branch. Bob --- ## #78330 — Stas Malyshev — 2014-10-25T18:20:46+00:00 URL: https://externals.io/message/78456#78330 · In reply to: #78325 Hi! > 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. I would like to weigh in here. If we're talking about things in PHP core repo, "we did it somewhere in public repo and nobody complained" is not a good stance. People do literally hundreds of things around PHP in public places, but not everything is part of PHP core. phpdbg now is. That involves not only good parts (by-default acceptance by millions of PHP users) but some obligations - like proper discussion and notification. Of course, since master is not stable yet, we have somewhat relaxed rules there, but even then introducing new debugging protocol into PHP core seems to be something that warrants some notification. As a person who spent significant time on implementing and maintaining one of PHP debugging solutions in the past, I, for example, would be interested to take a look into what is being checked into core repo in this regard. However, the first note I see about this happening is the commit messages. And that takes us back to old and not-so-good "check in first, discuss later" times. With project of the size of PHP, it having good process matters no less than having good code. So saying "we had this branch for whole three weeks before merging it into PHP repo" is not really saying much. That said, we are where we are, and I think it would be great if this would somehow server as a starting point for developing a unified protocol for debugging PHP. There are a number of good tools for debugging PHP, and it would be a pity if everybody invented their own protocols and required to install half-dozen of extensions to be compatible with all tools doing the same in slightly different way. We have so many unification efforts with PSR and the spec and so on, I'm pretty sure we can make a protocol that would be workable for all, debugging PHP is not exactly rocket surgery and there are not that many things there that we couldn't find a common ground. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #78331 — Joe Watkins — 2014-10-25T20:24:27+00:00 URL: https://externals.io/message/78456#78331 · In reply to: #78330 > Hi! > > > […] > > I would like to weigh in here. If we're talking about things in PHP core > repo, "we did it somewhere in public repo and nobody complained" is not > a good stance. People do literally hundreds of things around PHP in > public places, but not everything is part of PHP core. phpdbg now is. > That involves not only good parts (by-default acceptance by millions of > PHP users) but some obligations - like proper discussion and > notification. Of course, since master is not stable yet, we have > somewhat relaxed rules there, but even then introducing new debugging > protocol into PHP core seems to be something that warrants some > notification. As a person who spent significant time on implementing and > maintaining one of PHP debugging solutions in the past, I, for example, > would be interested to take a look into what is being checked into core > repo in this regard. However, the first note I see about this happening > is the commit messages. And that takes us back to old and not-so-good > "check in first, discuss later" times. With project of the size of PHP, > it having good process matters no less than having good code. I'd like to everyone to stay grounded in reality and say that we have been checking code into php-src for months, very very few people have expressed an interest in what we were actually doing, you aren't one of them Stas. There was a remote protocol at the start, it still exists, it was changed slightly. XML was added as an option. None of the decisions taken were questionable, in the slightest. While we should have given internals a heads up, it would have not have changed the outcome. We will notify internals of our intentions to make such changes in future, if we thought there was any chance of any feedback before today, we would already be doing so. > > So saying "we had this branch for whole three weeks before merging it > into PHP repo" is not really saying much. > > That said, we are where we are, and I think it would be great if this > would somehow server as a starting point for developing a unified > protocol for debugging PHP. There are a number of good tools for > debugging PHP, and it would be a pity if everybody invented their own > protocols and required to install half-dozen of extensions to be > compatible with all tools doing the same in slightly different way. > We have so many unification efforts with PSR and the spec and so on, I'm > pretty sure we can make a protocol that would be workable for all, > debugging PHP is not exactly rocket surgery and there are not that many > things there that we couldn't find a common ground. I quite like that idea, however, I'm stretched too thin to say that I can do anything about it. Cheers Joe --- ## #78332 — johannes@schlueters.de — 2014-10-26T00:03:35+00:00 URL: https://externals.io/message/78456#78332 · In reply to: #78331 disclaimer: I'm not overly interested in phpdbg, maybe I should be, but for the moment I'm not. > I'd like to everyone to stay grounded in reality and say that we have > been checking code into php-src for months, very very few people have > expressed an interest in what we were actually doing, you aren't one of > them Stas. The observation that very few people comment on your commits is correct, the conclusion unfortunately isn't. The thing is: only very few people are actively reviewing commits at all. Of those few only few look deeper into commits ... unfortunately we don't have a good review rate. As long as tests pass barely anybody complains about when things change. This is not phpdbg specific but is true for most parts of PHP, on the engine we have a few eyes, and a few extension maintainers have highlighting filters on commits touching their extensions, but that's a minority. This partly comes from people assuming that bigger changes will be announced on internals, probably even with RFC. Even though there are people who want an RFC&vote for everything I'd give extension (and sapi) maintainers some freedom ... but the line is a tough one ... The other reason is that reading commits is tough and requires a lot of time ... I have no idea how to give incentives to do more review but we desperately need that (again: not phpdbg specific but for the full project) one approach to solve that would be to require reviews (either in a Linux-like way with maintainers pulling changes and signing them off, taking responsibility that way, or in a tool-based way like Android with gerrit or such requiring reviews before a change is actually pushed into the repo) to push any changes but then again our project is too small and in some areas we can be happy to have somebody working on bugfixes at all ... enforcing reviews there will slow us down and add quite some process cost ... maybe somebody finds a good way ... johannes --- ## #78333 — Sebastian Bergmann — 2014-10-26T07:11:20+00:00 URL: https://externals.io/message/78456#78333 · In reply to: #78330 Am 25.10.2014 um 20:20 schrieb Stas Malyshev: > somewhat relaxed rules there, but even then introducing new debugging > protocol into PHP core seems to be something that warrants some > notification. That would have been my next question. I think it does not only warrant notification but adherence to the RFC process. --- ## #78336 — Pierre Joye — 2014-10-26T11:58:19+00:00 URL: https://externals.io/message/78456#78336 · In reply to: #78331 > I'd like to everyone to stay grounded in reality and say that we have > been checking code into php-src for months, very very few people have > expressed an interest in what we were actually doing, you aren't one of > them Stas. As much as I do not like the way this topic was brought to the list. A point has been raised. The chnages done in the latest patches, like the XML based protocol, are not small changes and will affect us, our users and external tools for a long time.I understand that discussing things too much prior to apply it takes time, energy and sometimes could kill the motivation, but this is how we reach consensus. I do not think it is too late to have this discussion, maybe part of the php specification too.I am a big fan of phpstorm, but it is by far not the only tool around. The discussions here, if we filter out the classic bashing and not so well formulated critics, try to figure out if the choices are actually the best ofr php, now and for the next years. So. Yes, I also have to ask, humbly, both of you to also stay grounded and accept to participate in a constructive discussion. Maybe push up a RFC, documenting the current XML protocol, see the pros/cons, etc. Other can also join this effort. I am sure we can find answers to all these questions soon, if we leave the sentimental parts of this discussions out of this, focusing on the actual technical and design facts. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #78337 — Bob Weinand — 2014-10-26T12:27:09+00:00 URL: https://externals.io/message/78456#78337 · In reply to: #78336 > Am 26.10.2014 um 12:58 schrieb Pierre Joye : > > > > > […] > > > As much as I do not like the way this topic was brought to the list. A > point has been raised. > > The chnages done in the latest patches, like the XML based protocol, > are not small changes and will affect us, our users and external tools > for a long time.I understand that discussing things too much prior to > apply it takes time, energy and sometimes could kill the motivation, > but this is how we reach consensus. > > I do not think it is too late to have this discussion, maybe part of > the php specification too.I am a big fan of phpstorm, but it is by far > not the only tool around. The discussions here, if we filter out the > classic bashing and not so well formulated critics, try to figure out > if the choices are actually the best ofr php, now and for the next > years. > > So. Yes, I also have to ask, humbly, both of you to also stay grounded > and accept to participate in a constructive discussion. Maybe push up > a RFC, documenting the current XML protocol, see the pros/cons, etc. > Other can also join this effort. I am sure we can find answers to all > these questions soon, if we leave the sentimental parts of this > discussions out of this, focusing on the actual technical and design > facts. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org I’m fully aware that this is a phpng-style push in a bit smaller scope. And, despite whether that’s in spirit of open source (I’m not so sure if it really isn’t), it was something that had to be done. It’s not yet too late, we can still polish things which aren’t fine in the protocol. Also, it was *necessary* to write the patch first to see how the protocol will also fit a bit into the code. But then I had to restructure the code a lot. And later the thing got so big it got just too much maintenance work to simultaneously develop on the master branch (in krakjoe/phpdbg repo) and xml-protocol branch, so I merged everything. By that time I had a lot of unrelated features and the XML protocol then in master. (At that point I didn’t think it might become an issue). Then more than a week later I found it relatively stable (maybe some polishing left, but ± stable). I considered to have more discussion before, but it’d have blocked all the other improvements pending (would probably have been too much work to separate things again and push). And one really needs a starting base before real discussion can take place (The patch alone IMO is anyway too big to be reviewed as is). So, I pushed. But let us not discuss if it really was a good idea to have it done that way - or not. Please rather discuss where the protocol can be improved, if it’s missing some features etc. There is a Markdown file about the protocol in sapi/phpdbg/xml.md, which is documenting the XML responses one might get. I’m aware that it’s not really well structured, I appreciate any help there. But mainly, please first review if the design of the protocol is okay. Quick info (because it already caused some confusion): input commands are the same for xml protocol than for interactive mode. It’s just the output which differs. Bob p.s.: I don’t regret to have chosen XML - I mean, it’s now to late to discuss whether to choose XML or not, but I don’t regret the decisions I made there. --- ## #78338 — Derick Rethans — 2014-10-26T15:09:01+00:00 URL: https://externals.io/message/78456#78338 · In reply to: #78321 > > > […] > > A few weeks ago, I was at a conference where you told a room filled > with hundreds of developers that phpdbg was no good, because you don't > know how to use it. I was being polite. I should have told them it is useles for any of our users, instead of blaming it (wrongly) on my own ineptitude. > This is a strange sort of silence, and does not invite us to > co-operate. Neither does calling internals people "dicks" or "knobs". > When you invented dbgp there were other protocols in existence, There indeed where, but none of them were either open, or supporting more than one language. As that was the goal, the people from ActiveState—which *still, ten years later* have the best debugger frontend—and I sat around a table and implemented a language-agnostic debugging protocol. Used by Xdebug, and their debuggers for perl, python, tcl, ruby, and XSLT. > not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. > It so happens that the phpstorm guys working on integration seemed > keen on something new. I don't see the problem in that. If the only > reason it exists is for projects like phpstorm and they are actually > going to put time into trying something new, then why the hell not. Well, if you'd have used DBGp, they wouldn't have to do any work. > I'm not sure why it matters what kind of language we use on > phpdbg.com, not sure why you think it should be under the control of > the php group either. It shouldn't be anywhere near the PHP group either. It is run as a personal project with source dumps into PHP. Things run like that have no place in the core distribution. If you want to run your personal project, go ahead - but keep php.net out of it. > If you had wanted to co-operate, you could have spoken to me at that > conference in person, I tried. You disappeared after the first afternoon. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #78339 — Andrea Faulds — 2014-10-26T15:11:57+00:00 URL: https://externals.io/message/78456#78339 · In reply to: #78338 > > > > > > […] > > I was being polite. I should have told them it is useles for any of our > users, instead of blaming it (wrongly) on my own ineptitude. Perhaps you could’ve actually talked about its benefits. I went to that talk too. You showed off stuff vld can do… and neglected to mention that phpdbg could do the same things. -- Andrea Faulds http://ajf.me/ --- ## #78340 — Derick Rethans — 2014-10-26T15:17:29+00:00 URL: https://externals.io/message/78456#78340 · In reply to: #78325 > 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 --- ## #78341 — Derick Rethans — 2014-10-26T15:18:17+00:00 URL: https://externals.io/message/78456#78341 · In reply to: #78326 > > > […] > > Thanks Bob. > > So my question is: Obviously the phpdbg requirements do not map to > DBGp. However, can all of the requirements of DBGp be mapped to the > phpdbg XML? > > Going forward does the XML protocol cover everything XDebug needs? Can > we do "DBGp over XML"? DBGp is XML. This question makes no sense. cheers, Derick --- ## #78342 — Derick Rethans — 2014-10-26T15:20:08+00:00 URL: https://externals.io/message/78456#78342 · In reply to: #78330 > That said, we are where we are, and I think it would be great if this > would somehow server as a starting point for developing a unified > protocol for debugging PHP. It already exists: DBGp. It's implemented by dozens of editors and plugins. cheers, Derick --- ## #78343 — Derick Rethans — 2014-10-26T15:22:20+00:00 URL: https://externals.io/message/78456#78343 · In reply to: #78331 > We will notify internals of our intentions to make such changes in > future, if we thought there was any chance of any feedback before today, > we would already be doing so. "We will notify internals". Really? Sadly, this phpdbg stuff is part of internals, so the "we" and "internals" mean the same thing. If you want to run this as a private project, get it out of php-src. cheers, Derick --- ## #78345 — Bob Weinand — 2014-10-26T15:26:05+00:00 URL: https://externals.io/message/78456#78345 · In reply to: #78340 > Am 26.10.2014 um 16:17 schrieb Derick Rethans : > > > > > […] > > 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. > > […] > > 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. > > […] > > > […] > > Indeed - it's after all a documented 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. > > […] > > 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.) > > […] > > > […] > > 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 > -- > > Thanks, Bob --- ## #78344 — Derick Rethans — 2014-10-26T15:26:06+00:00 URL: https://externals.io/message/78456#78344 · In reply to: #78339 > > > […] > > Perhaps you could’ve actually talked about its benefits. I went to > that talk too. You showed off stuff vld can do… and neglected to > mention that phpdbg could do the same things. Some of it, certainly. A future version of the talk (ie, next week at ZendCon) will show the difference, so that the audience can judge for themselves what is better. cheers, Derick --- ## #78346 — Bob Weinand — 2014-10-26T15:28:26+00:00 URL: https://externals.io/message/78456#78346 · In reply to: #78343 > Am 26.10.2014 um 16:22 schrieb Derick Rethans : > > > > > […] > > "We will notify internals". Really? Sadly, this phpdbg stuff is part of > internals, so the "we" and "internals" mean the same thing. If you want > to run this as a private project, get it out of php-src. > > cheers, > Derick As already said, it was an one-time mistake. If there are any major things to happen in phpdbg, we’ll drop a mail first here and only merge after eventual discussion. Thanks, Bob --- Next page: https://externals.io/message/78456.md?page=2