Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78625
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <5458AE36.5090601@lsces.co.uk>
Date: Tue, 04 Nov 2014 10:45:10 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
References: <alpine.DEB.2.11.1411031940310.13538@whisky.home.derickrethans.nl>	 <1415080851.2624.344.camel@localhost.localdomain>	 <54589A18.4080703@lsces.co.uk> <1415093847.2624.354.camel@localhost.localdomain>
In-Reply-To: <1415093847.2624.354.camel@localhost.localdomain>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHPDBG scope
From: lester@lsces.co.uk (Lester Caine)

On 04/11/14 09:37, Joe Watkins wrote:
> On Tue, 2014-11-04 at 09:19 +0000, 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