Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Wed, 2014-10-29 at 17:08 -0700, Derick Rethans wrote: On Sun, 26 Oct 2014, Bob Weinand wrote: Am 26.10.2014 um 16:09 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: 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. 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. No, xDebug has its use cases, phpdbg other use cases. They overlap many times. And it’s definitely not useless. I’ve already been able to debug real things with phpdbg and it works nicely for me. I think this hits something on the spot: we don't define scope in an RFC. And scope creep is never a good thing. I would suggest that you come up with what scope phpdbg should solve, and don't get out of it. This is a strange sort of silence, and does not invite us to co-operate. Neither does calling internals people dicks or knobs“. That’s definitely a bad thing… could we please leave this genre of discussion out of internals? Sorry, I think that it should be called out *just* because it's not appropriate in any case. 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. Hmm? I hardly could find anything about that with a few google searches... http://code.activestate.com/komodo/remotedebugging/ http://en.wikipedia.org/wiki/Project_Zero#PHP_support http://hhvm.com/blog/6239/hhvm-3-3-0 not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. Because something is used by the only open-source thing in a field, it doesn’t make it a standard. That you definitely have gotten wrongly. I used virtually as adjective. I perhaps should have used de facto[1]. [1] http://dictionary.reference.com/browse/de%20facto 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. Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. So I actually did talk to them (in person, at ZendCon), and their account of events is pretty much the exact opposite. But in any case, that doesn't mean that reinventing the wheel again makes sense. It's certainly not helpful to for users, for which you are now fragmenting support. 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. Maybe, but if you wouldn’t have given such a negatively talk on the phpdbg part, he maybe wouldn’t have disappeared. Where you there? I don't think so. So please don't judge people on here-say information. cheers, Derick Morning, This is new information to me, I was lead to believe that phpstorm were happy to invest time in it. I asked bob for the xml stuff to be reverted from 5.6 and master yesterday and be developed elsewhere. This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* be carried out in an experimental branch of php-src, or on krakjoe/phpdbg. About scope, we never intended to write a remote debugger suitable for everything, we were pushed down that road by what people seem to
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
This is new information to me, I was lead to believe that phpstorm were happy to invest time in it. I asked bob for the xml stuff to be reverted from 5.6 and master yesterday and be developed elsewhere. This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* be carried out in an experimental branch of php-src, or on krakjoe/phpdbg. About scope, we never intended to write a remote debugger suitable for everything, we were pushed down that road by what people seem to want. phpdbg is fundamentally different to xdebug, it cannot be loaded in any SAPI, it doesn't even make sense to talk about using it in the same way as xdebug, it does not and can not do all the things. I'm quite happy for phpdbg to have better remote abilities, I even said that we should use dbgp https://github.com/krakjoe/phpdbg/issues/105 I'd be even happier if we left that to xdebug, we never wanted to focus on that in the beginning. The remote ability that phpdbg had at the beginning was for no more than giving people uncomfortable with using a shell, or not able to use a shell, an option. It worked, but was arguably terrible, and an afterthought. I think it would be better for everyone if we dropped the idea of support for remote debugging, I won't stop it going ahead if bob still wants to work on it, but I do regard it as feature creep. I see a clear usecase for remote debugging and shell. Same shell usage as now but with remote host support. I do that a lot for many other languages, testing stuff in various VMs. It is amazingly handy to be able to do that. As of 5.6, I am not sure either with other big changes as 5.6 is stable now, huge changes (and not well tested, builds were broken f.e.) should be done after (public) discussions, if necessary. Cheers, -- 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 Thu, 2014-10-30 at 14:56 +0700, Pierre Joye wrote: This is new information to me, I was lead to believe that phpstorm were happy to invest time in it. I asked bob for the xml stuff to be reverted from 5.6 and master yesterday and be developed elsewhere. This now *must* happen, it doesn't belong in php-src at this point. If development of a remote protocol is to be carried out, it *must* be carried out in an experimental branch of php-src, or on krakjoe/phpdbg. About scope, we never intended to write a remote debugger suitable for everything, we were pushed down that road by what people seem to want. phpdbg is fundamentally different to xdebug, it cannot be loaded in any SAPI, it doesn't even make sense to talk about using it in the same way as xdebug, it does not and can not do all the things. I'm quite happy for phpdbg to have better remote abilities, I even said that we should use dbgp https://github.com/krakjoe/phpdbg/issues/105 I'd be even happier if we left that to xdebug, we never wanted to focus on that in the beginning. The remote ability that phpdbg had at the beginning was for no more than giving people uncomfortable with using a shell, or not able to use a shell, an option. It worked, but was arguably terrible, and an afterthought. I think it would be better for everyone if we dropped the idea of support for remote debugging, I won't stop it going ahead if bob still wants to work on it, but I do regard it as feature creep. I see a clear usecase for remote debugging and shell. Same shell usage as now but with remote host support. I do that a lot for many other languages, testing stuff in various VMs. It is amazingly handy to be able to do that. As of 5.6, I am not sure either with other big changes as 5.6 is stable now, huge changes (and not well tested, builds were broken f.e.) should be done after (public) discussions, if necessary. Cheers, Morning, Some remote ability is helpful, I agree. The kind of remote ability we had at the start is, in my opinion, as far as it ever really needs to go. The use case for remote debugging, using any sapi, will always be best satisfied by xdebug. If we are to develop the remote debugging features with an extended or new version of dbgp, then 7 is the only sensible target for that I think, if there is a sensible target. 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: ...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 29/10/2014 00:35, Stas Malyshev a écrit : Hi! phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? Can you please consider reverting everything to stable state (5.6.2), and start discussing about pending changes ? Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRQijwACgkQYUppBSnxahiPugCfWBHUcWQlFqq4tx/KrC95VqUK CsAAoN4YcKahsp3WFIX0CkEA7g7gDhrV =p9SK -END PGP SIGNATURE- -- 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 29/10/2014, at 12:43 AM, Julien Pauli jpa...@php.net wrote: On Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra d...@php.net wrote: On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. step back a bit here, stay professional, there is no need for passive aggressiveness. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Hello people. When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR FYI, PHP-FPM still has a separate website. Cheers, David -- 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 Wed, Oct 29, 2014 at 12:35 AM, Stas Malyshev smalys...@gmail.com wrote: Hi! phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? If you are talking about the phpdbg new debugging protocol : this is right. I think it clearly lacks discussion, RFC, concensus here, particularly regarding the choice of the protocol. We must absolutely use something open and efficient. Using a closed protocol, that only one editor would be able to implement ; is just a no-go ; for example. Julien.P -- 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 Wed, Oct 29, 2014 at 9:10 AM, David Muir davidkm...@gmail.com wrote: On 29/10/2014, at 12:43 AM, Julien Pauli jpa...@php.net wrote: On Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra d...@php.net wrote: On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. step back a bit here, stay professional, there is no need for passive aggressiveness. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Hello people. When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR FYI, PHP-FPM still has a separate website. Yep, this came to my ears recently. I forgot about it. I have nothing against external web site, as soon as the PHP doc is clear, up-to-date and detailed. For phpdbg , this is actually not the case (yet ?), there is WIP however. Julien.P -- 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 Sun, 26 Oct 2014, Bob Weinand wrote: Am 26.10.2014 um 16:22 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: 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. 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. That's good to hear. But I have been speaking to the PhpStorm people here at ZendCon, and they give a different version of the story why you didn't pick DBGp. From what I understand, having to do another debugging protocol is really the last thing that they want. Drop me a line (privately) to see whether we can resolve the issues with the protocol that you had. cheers, Derick -- 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 Sun, 26 Oct 2014, Bob Weinand wrote: Am 26.10.2014 um 16:09 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: On Fri, 24 Oct 2014, Bob Weinand wrote: 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. 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. No, xDebug has its use cases, phpdbg other use cases. They overlap many times. And it’s definitely not useless. I’ve already been able to debug real things with phpdbg and it works nicely for me. I think this hits something on the spot: we don't define scope in an RFC. And scope creep is never a good thing. I would suggest that you come up with what scope phpdbg should solve, and don't get out of it. This is a strange sort of silence, and does not invite us to co-operate. Neither does calling internals people dicks or knobs“. That’s definitely a bad thing… could we please leave this genre of discussion out of internals? Sorry, I think that it should be called out *just* because it's not appropriate in any case. 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. Hmm? I hardly could find anything about that with a few google searches... http://code.activestate.com/komodo/remotedebugging/ http://en.wikipedia.org/wiki/Project_Zero#PHP_support http://hhvm.com/blog/6239/hhvm-3-3-0 not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. Because something is used by the only open-source thing in a field, it doesn’t make it a standard. That you definitely have gotten wrongly. I used virtually as adjective. I perhaps should have used de facto[1]. [1] http://dictionary.reference.com/browse/de%20facto 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. Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. So I actually did talk to them (in person, at ZendCon), and their account of events is pretty much the exact opposite. But in any case, that doesn't mean that reinventing the wheel again makes sense. It's certainly not helpful to for users, for which you are now fragmenting support. 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. Maybe, but if you wouldn’t have given such a negatively talk on the phpdbg part, he maybe wouldn’t have disappeared. Where you there? I don't think so. So please don't judge people on here-say information. cheers, Derick -- 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 Mon, Oct 27, 2014 at 6:27 PM, David Soria Parra d...@php.net wrote: On 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. step back a bit here, stay professional, there is no need for passive aggressiveness. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Hello people. When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Xdebug is *not* a php.net project, and Derick hash always managed to keep this line clear to everybody (since 10 years now). Derick has never asked to merge Xdebug to core, because (please confirm) probably he wants to keep the lead on the project, and make it evolve like *he, as author and maintainer* wants to. This is something that can not happen to a PHP-project code. phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to adhere the rules, you can keep your ideas yours, in a separate repo, like Derick does for Xdebug. People must understand that as soon as the code is part of the PHP project, it is owned by the PHP project, and not a single/duo person anymore. Julien.Pauli -- 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 28 Oct 2014, at 13:43, Julien Pauli jpa...@php.net wrote: When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net. -- Andrea Faulds http://ajf.me/ -- 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 Tue, Oct 28, 2014 at 2:50 PM, Andrea Faulds a...@ajf.me wrote: On 28 Oct 2014, at 13:43, Julien Pauli jpa...@php.net wrote: When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net. Yes, this has been like that since the beggining of the PHP project. The PHP project is a human, collaborative open source adventure before anything else. The code and the ideas written behind php.net are collaborative and owned by everyone. Julien.P -- 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 Sun, Oct 26, 2014 at 8:11 AM, Sebastian Bergmann sebast...@php.net wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As far as I can tell there are a couple of SAPIs(to be honest everything except cli/cgi/fpm/embed and apache*) and even some exts(like mysql*, pgsql, date, pcre, etc.) where there are dedicated maintainers who seemingly can introduce new features without discussing it on the list or following through the rfc process. I'm not saying that this is a bad thing(on the contrary, I think that most of the times this happens because the maintainer is the best suited for making those decisions), but I think it would be nice if we could clarify that what exact procedures do we want to be followed for exts/SAPIs inside the php-src tree. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 28.10.2014 um 14:50 schrieb Andrea Faulds a...@ajf.me: On 28 Oct 2014, at 13:43, Julien Pauli jpa...@php.net wrote: When PHP 5.6 has been released, few weeks/months ago, I explicitely stated Ferenc (RMing 5.6 together with me), that *it is not a normal thing to have an external domain for phpdbg* This has never happened before, FWIR Every code that is part of PHP, that is merged into php.net repo , falls under the PHP licence *and* the PHP process of doing things. One chance is that today the subject shows to everybody and not only RM wondering about this. Cool. I'm all +1 to merge phpdbg web site content into official php.net documentation. Guys, from an external POV, phpdbg seems very strange for people. Why the hell does it have its own github repo and its own website ? This is something that has never been seen for *official* php.net content and our users are asking questions / assuming things. Yeah, I agree this is weird. There’s nothing wrong with keeping around the github repo to provide phpdbg for older PHP versions, but the main site should on php.net and it shouldn’t tell the user to go anywhere but php.net. -- Andrea Faulds http://ajf.me/ http://ajf.me/ Just a tiny update on this subject: we’re working on it. https://github.com/bwoebi/phpdbg-docs https://github.com/bwoebi/phpdbg-docs is in markdown what’ll be at some point in the official docs, I hope. It may take some little time to finish this, but then we’ll probably redirect phpdbg.com http://phpdbg.com/ page to php.net http://php.net/. The phpdbg.com http://phpdbg.com/ page is currently just horribly outdated and a relict from that time before phpdbg was merged into php-src. Bob Weinand
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Hi! phpdbg is under php.net ; every decision about phpdbg should then be debatted with all the team, and new ideas, such as a protocol, RFC'ed, whoever are the maintainers of the code. It's like that for every piece of code, of every extension. This is PHP process. If you dont want to Do I understand it right that after all we've being discussing here about not putting big new stuff into PHP without discussion, we've got new stuff in phpdbg now merged not only to master but into the stable branch of 5.6? Am I missing something here? -- 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 2014-10-26, Bob Weinand bobw...@hotmail.com wrote: Am 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. step back a bit here, stay professional, there is no need for passive aggressiveness. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. From what I see, the complan is about the initial protocol and not about how to improve it or not. This whole protocol business needed an RFC, which I haven't seen. So we should come up with a good way of deciding which protocol to use and how to implement it. Before this, I would strongly vote to not incldue the current verison in PHP 7 at all. Also let me point out that the code belogns to everyone and everyone will have to deal with it so we better make an informed decision now. Thanks -- 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 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. -- 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 Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins pthre...@pthreads.org 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. 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 -- 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 26.10.2014 um 12:58 schrieb Pierre Joye pierre@gmail.com: On Sun, Oct 26, 2014 at 3:24 AM, Joe Watkins pthre...@pthreads.org 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. 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 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.
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On Sat, 25 Oct 2014, Joe Watkins wrote: 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. 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 -- 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 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: 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. 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/ -- 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, 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 -- 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, 25 Oct 2014, Leigh wrote: 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? DBGp is XML. This question makes no sense. cheers, Derick -- 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, 25 Oct 2014, Stas Malyshev wrote: 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 -- 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, 25 Oct 2014, Joe Watkins wrote: 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 -- 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 Sun, 26 Oct 2014, Andrea Faulds wrote: On 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: 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. 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 -- 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 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
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
Am 26.10.2014 um 16:22 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: 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 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 -- 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 26.10.2014 um 16:26 schrieb Derick Rethans der...@php.net: On Sun, 26 Oct 2014, Andrea Faulds wrote: On 26 Oct 2014, at 15:09, Derick Rethans der...@php.net wrote: On Sat, 25 Oct 2014, Joe Watkins wrote: On Fri, 2014-10-24 at 23:06 -0400, Derick Rethans wrote: 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. 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 I’m certain it’ll still be biased somehow. Would be great if you could share with us what you’ll tell them, then maybe you can do a constructive talk about it. Thanks, 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 26.10.2014 um 16:09 schrieb Derick Rethans der...@php.net: On Sat, 25 Oct 2014, Joe Watkins wrote: 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. 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. No, xDebug has its use cases, phpdbg other use cases. They overlap many times. And it’s definitely not useless. I’ve already been able to debug real things with phpdbg and it works nicely for me. This is a strange sort of silence, and does not invite us to co-operate. Neither does calling internals people dicks or knobs“. That’s definitely a bad thing… could we please leave this genre of discussion out of internals? 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. Hmm? I hardly could find anything about that with a few google searches... not sure why we are expected to reuse a protocol. Because DBGp is virtually a standard in the PHP world. Because something is used by the only open-source thing in a field, it doesn’t make it a standard. That you definitely have gotten wrongly. 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. Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. I'm not sure why it matters what kind of language we use on phpdbg.com http://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 http://php.net/ out of it. phpdbg.com http://phpdbg.com/ is outdated, massively. That’s why we’re currently aiming to get a meaningful documentation to php.net http://php.net/. 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. Maybe, but if you wouldn’t have given such a negatively talk on the phpdbg part, he maybe wouldn’t have disappeared. Maybe you just could have talked to Joe before and discussed constructively about phpdbg. cheers, Derick -- http://derickrethans.nl http://derickrethans.nl/ | http://xdebug.org http://xdebug.org/ Like Xdebug? Consider a donation: http://xdebug.org/donate.php http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine
Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...)
On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- 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 26.10.2014 um 17:23 schrieb Lester Caine les...@lsces.co.uk: On 26/10/14 15:41, Bob Weinand wrote: Ask them at PhpStorm. They were pleased to not have to use DBGp for it. They just initially requested it because they didn’t knew any better protocol. That’s all. PHPStorm like PHP-FIG have their own agendas which do not play well with other groups of developers. Just because one thinks an idea is good does not mean that everybody else has to adopt it. So what becomes 'main stream' has to have common consensus and the voting rules provide that. When was the vote on this rework taken? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk There wasn’t any vote and there won’t. /dev/null likes to listen to your complaints why we should have voted on it. But now it’s in, let’s rather try to improve what’s there than screaming for a vote - it won’t help anyone and hinder possible work on improving the current thing. Next time we’ll put a notice a few days before, it’s promised, yes. Thanks, 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: ...)
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
