This topic has been locked.
4 replies Latest Post - 2012-10-04T18:51:31Z by John.
Pinned topic 99250
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-10-04T18:51:31Z at 2012-10-04T18:51:31Z by John.
alainr345 120000CBQQ1 PostACCEPTED ANSWER
test2010-04-21T02:04:03Z in response to SystemAdminGood contribution to a very arcane field (free PHP debugging). I have a question though:
I did setup the environment on Windows XT (took me a long time, I had to backtrack my PHP version and find the DBG instructions at http://www.php-debugger.com/dbg/installation.php, your plog4u link is outdated) and finally had the breakpoints and variable inspection, etc. It's great to have something working that has been around for 10 years on Java and 20 on C++. I guess that's what they call progress... The debugBreak() call does not work for me (the php_dbg.dll crashes) but that's not a problem since regular Eclipse breakpoints do work. Now, the very annoying thing is that the buffer flushing patch you suggest does NOT do anything (the HTML page shows up only at the end after the parser is left). I tried a longer sleep, NOTHING. I tried putting: header("Cache-Control: no-cache, must-revalidate"); header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); while (@ob_end_flush()); ob_get_flush(); NOTHING. I tried in php.ini: output_buffering = 0 and implicit_flush = On, NOTHING. I have Eclipse 3.4, PHPEclipse 1.2.3, Apache 2.2, PHP 5.2, DBG 5.2
Thanks for any tip, A. R.
MrBaseball34 270003E0C51 PostACCEPTED ANSWER
test2010-08-19T18:51:08Z in response to SystemAdminquoteNow, the very annoying thing is that the buffer flushing patch you suggest does NOT do anything (the HTML page shows up only at the end after the parser is left)[/quote]
I have also found that running on localhost on WindowsXP that the output buffering isn't what it should be.
John. 270005QX3S1 PostACCEPTED ANSWER
test2012-10-04T18:51:31Z in response to SystemAdminOn debugging with print statements...
I tend to call it "instrumenting" the code, and if you use the sourceforge debugobject project
(located here: https://sourceforge.net/projects/debugobject/ )
it's very easy to write the debug code you need, and leave it in the code. This helps maintain applications that have a long lifespan. You only turn it on only when you want it on, and it's easy to turn on a given scope (function, file, namespace, class, etc), and a given level in that scope, and you can turn on multiple scopes at the same time (so, 4 or 5 key functions. for example). It's worth checking out.