Re: [PHP-DEV] PHPDBG scope
On 04/11/14 06:00, Joe Watkins wrote: I'm not saying we should not extend the features of phpdbg, but, we should do it knowing what it actually is, knowing that it is fundamentally different to xdebug. Having just hit another 'white screen' problem on a site I'm trying to update, I do wonder if there is an alternative debug approach that would help speed the process. I have used xdebug in the past, but on the whole the debug tools built into the framework allow fairly quick tracking of a problem and isolating it. So the question is ... just where are the strengths of each and is either useful for day to day debugging, or more appropriate for debugging the internal operation of PHP? -- 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 scope
On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote: On 04/11/14 06:00, Joe Watkins wrote: I'm not saying we should not extend the features of phpdbg, but, we should do it knowing what it actually is, knowing that it is fundamentally different to xdebug. Having just hit another 'white screen' problem on a site I'm trying to update, I do wonder if there is an alternative debug approach that would help speed the process. I have used xdebug in the past, but on the whole the debug tools built into the framework allow fairly quick tracking of a problem and isolating it. If you were to enable xdebug, I am sure it could give you some insight. As could switching all errors to exceptions temporarily, maybe. A white screen often has the root cause suppressed by error_level, executing in the appropriate way in phpdbg would break on errors, telling you where the problem originates, possibly. So the question is ... just where are the strengths of each and is either useful for day to day debugging, or more appropriate for debugging the internal operation of PHP? A considerable strength of a standalone debugger, is that it is standalone :) You don't need an IDE or any other client, a server, or any other software to debug some code, you just need a debugger. We don't deploy code like this however, so while phpdbg might be able to provide some insight in some cases, xdebug is how we debug code that is deployed in a normal server environment. It depends what you do day-to-day, as mentioned, if you are someone comfortable with, or who spends a considerable amount of time in a console, for whatever reason, then phpdbg can certainly be a useful tool. When it comes to debugging our deployments however, nothing has changed. -- 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 Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG scope
On 04/11/14 09:37, Joe Watkins wrote: On Tue, 2014-11-04 at 09:19 +, Lester Caine wrote: On 04/11/14 06:00, Joe Watkins wrote: I'm not saying we should not extend the features of phpdbg, but, we should do it knowing what it actually is, knowing that it is fundamentally different to xdebug. Having just hit another 'white screen' problem on a site I'm trying to update, I do wonder if there is an alternative debug approach that would help speed the process. I have used xdebug in the past, but on the whole the debug tools built into the framework allow fairly quick tracking of a problem and isolating it. If you were to enable xdebug, I am sure it could give you some insight. As could switching all errors to exceptions temporarily, maybe. A white screen often has the root cause suppressed by error_level, executing in the appropriate way in phpdbg would break on errors, telling you where the problem originates, possibly. I think this is perhaps where I'm struggling having moved from Apache to nginx/fastcgi. Traditionally we have always run with display_errors on since any error is a sign that something needs looking at! This is why having to switch off errors to maintain 'BC' with older code is a pain. I'd forgotten it had been switched off to keep something else working :( But there is nothing in the log file either ... hence needing to sort out what I SHOULD be doing. So the question is ... just where are the strengths of each and is either useful for day to day debugging, or more appropriate for debugging the internal operation of PHP? A considerable strength of a standalone debugger, is that it is standalone :) You don't need an IDE or any other client, a server, or any other software to debug some code, you just need a debugger. We don't deploy code like this however, so while phpdbg might be able to provide some insight in some cases, xdebug is how we debug code that is deployed in a normal server environment. It depends what you do day-to-day, as mentioned, if you are someone comfortable with, or who spends a considerable amount of time in a console, for whatever reason, then phpdbg can certainly be a useful tool. When it comes to debugging our deployments however, nothing has changed. It's that many things have changed over the years resulting in many of the 'normal practices' no longer working the same way! My own day to day working method is still based around PHPEclipse which has both phpdbg and xdebug available but my notes on using them no longer work :( I know I'm going to have to give in and switch to PDT butit simply does not provide the same facilities that the now unsupported PHPEclise provides while debugging code. -- 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
[PHP-DEV] PHPDBG scope
Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want. And I very much agree that the above bullet points, is what phpdbg's scope should be. Joe, if I got this wrong, then please say so :-) 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 scope
Hi, Why should phpdbg scope be limited, and not extended? As far as I know, xdebug is nowhere like an official php project, so overlap shouldn't be an issue. I'm not saying phpdbg has to be extended, but I'm wondering why it should be limited. Regards, On Mon, Nov 3, 2014 at 10:03 PM, Derick Rethans der...@php.net wrote: Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want. And I very much agree that the above bullet points, is what phpdbg's scope should be. Joe, if I got this wrong, then please say so :-) 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 -- Florian Margaine
Re: [PHP-DEV] PHPDBG scope
Am 03.11.2014 um 22:03 schrieb Derick Rethans der...@php.net: Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests“. That was the initial purpose of phpdbg, correct. But now it has outgrown of itself, I think. But also, to begin something, you need concrete goals. In this case that was nice tiny debugger for cli PHP users and devs. Very true. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want.“ It wasn’t with that addition the flood gates opened. This addition came alongside with the initial xml protocol development (though in a separate branch), because I thought, if users are going to debug web apps, they most likely will need that. And true, we aren’t trying to usurp xdebug, it was planned to coexist. Nothing like competition, but it was asked that we make it debuggable by an IDE. The xml protocol stuff just was a consequence of that request, to make it possible. And I very much agree that the above bullet points, is what phpdbg's scope should be. Also, why do we want an arbitrarily narrowed scope? Joe, if I got this wrong, then please say so :-) cheers, Derick Regards, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG scope
Hi, Derick wrote: I asked him what the original scope of phpdbg was,... And I very much agree that the above bullet points, The original scope of a project and what it should be in the future are not related always related. Please don't pretend that they're the same thing. Derick wrote: I've summarized his reply here: Taking a private conversation and presenting it as what someone else agrees to is also an underhand tactic. From your emails to this list, you plainly wish to limit what PHPDBG does. You may even have valid reasons for those wishes, but please stop using underhand tactics to limit what other people are trying to do. cheers Dan On 3 November 2014 21:03, Derick Rethans der...@php.net wrote: Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want. And I very much agree that the above bullet points, is what phpdbg's scope should be. Joe, if I got this wrong, then please say so :-) 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPDBG scope
Hi! - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. That was also my impression when the RFC was discussed. Now, I do not object in principle on growing the scope of phpdbg. But this needs to be done the right way if it's the php.net core part - having an RFC that explains what exactly happens and why, getting consensus, and only then merging. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. I don't think this as such is a bad idea, I wouldn't mind having such thing available, I can see use cases where it would be handy. So I think it would be useful to have some ordered RFC describing where phpdbg wants to expand to and then we can discuss it and see if we can arrive at something that would be ok with everybody. -- 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 scope
On Mon, 2014-11-03 at 21:03 +, Derick Rethans wrote: Hi, This is based on an email conversation between Joe Watkins and me. I asked him what the original scope of phpdbg was, and I've summarized his reply here: - PHPDBG was originally envisioned as a gdb for the Zend VM, with gdb like commands to debug, and step through code. - Support for breaking on an opline, something that no userland PHP users would need. - Support for breaking on lines, was an additional step later. - For PHP programmers, which spend most of their time at the console. - Not intended to cover PHP's primary domain of HTTP requests. Then later, they documented a way that you could use it to emulate an HTTP request, by setting those superglobals and executing your index.php - your code doesn't know the difference between a real request, and a cli-like script with the same super globals set. And Joe indicates, that with that addition, the flood gates opened. He also said that he would still like to remain in that narrow scope, phpdbg is still useful in it's current (pre xml stuff) form. and that it was never meant to usurp xdebug, as that is not where we were aiming, and it's an extremely unrealistic thing to even want. And I very much agree that the above bullet points, is what phpdbg's scope should be. Joe, if I got this wrong, then please say so :-) 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 Morning Internals, Thank you Derick. Why should phpdbg scope be limited, and not extended? It's not about limiting the scope of phpdbg, it's about defining it properly. The right tool for the job is what we are talking about. phpdbg will *never* be able to do all the things xdebug can do, and it would ruin it to try. In the same way, there are things phpdbg can do that would further complicate xdebug (or even be impossible), and we shouldn't try that either, obviously. The original scope of a project and what it should be in the future are not always related True, but in this case it does actually matter. You will never be able to load phpdbg in any SAPI and debug any web request in a robust way. It was never intended for that, it is limited, in that sense, because it's a SAPI. Being a SAPI allows us to do things you cannot do in an extension, such as overriding Zend's memory management routines. We have features based on these abilities. I very much agree that we should keep phpdbg within the scope it was designed for. I'm not saying we should not extend the features of phpdbg, but, we should do it knowing what it actually is, knowing that it is fundamentally different to xdebug. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
