Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: Commit:2bcac53bca8ea82d661f057b6d9ff3c7c84f05a7 Author:Bob Weinand bobw...@hotmail.com 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 snip 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
hi, On Sat, Oct 25, 2014 at 1:13 PM, Joe Watkins pthre...@pthreads.org wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 2014-10-25 at 16:19 +0700, Pierre Joye wrote: hi, On Sat, Oct 25, 2014 at 1:13 PM, Joe Watkins pthre...@pthreads.org wrote: 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. 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, Oct 25, 2014 at 4:39 PM, Joe Watkins pthre...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 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@gmail.com: On Sat, Oct 25, 2014 at 4:39 PM, Joe Watkins pthre...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On 25 October 2014 12:00, Weinand Bob bobw...@hotmail.com wrote: ... 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 25.10.2014 um 13:25 schrieb Leigh lei...@gmail.com: On 25 October 2014 12:00, Weinand Bob bobw...@hotmail.com wrote: ... 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 25.10.2014 um 17:37 schrieb Sebastian Bergmann sebast...@php.net: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 2014-10-25 at 11:20 -0700, Stas Malyshev wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
disclaimer: I'm not overly interested in phpdbg, maybe I should be, but for the moment I'm not. On Sat, 2014-10-25 at 21:24 +0100, Joe Watkins wrote: 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 RFCvote 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
