PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (629 total including feature requests)
===[Apache related]===
36472 Feedback Memory fault
===[Apache2 related]
PHP 5 Bug Database summary - http://bugs.php.net
Num Status Summary (429 total including feature requests)
===[*Compile Issues]==
36404 Open configure script cannot complete libxml build
===
Extend PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Mac OS X has some tools for debugging and profiling. They may not be
as easy to use as valgrind, but they still work. http://
kernelthread.com/mac/osx/tools.html is a good overview of the most
important CLI tools (search for debug, profile, trace in the document).
The same guy has a fo
Hi,
I'd like to suggest that we revisit the output control (output buffering) code
base.
The current implementation uses way too less commands to do too many different
operations, which almost always causes problems with output handlers that need
to maintain a state or context.
Short example:
o
> I'd like to suggest that we revisit the output control
> (output buffering) code base.
> The current implementation uses way too less commands to do
> too many different operations, which almost always causes
> problems with output handlers that need to maintain a state
> or context.
>
> Sh
On 27 Feb 2006, at 03:17, Rasmus Lerdorf wrote:
When you manage that, please send me a copy of an OSX-PPC
compatible Valgrind!
Don't know if it helps, but kcachegrind works a treat on OS X. It's
just had an update via fink too.
Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in
Jeff Moore wrote:
> Would this patch (or another
> like it) allow for the elimination of the current recursion guard for
> __get, etc?
The code below echoes "it works" on PHP_5_1 and HEAD but raises a notice on
the other branches.
there;
case 'there':
return 'it wor
Michael Wallner wrote:
I'd like to suggest that we revisit the output control (output
buffering) code base.
On a semi-related note, I'd like to see the docs mention that print_r
and var_export (with the second parameter set to TRUE), and
debug_print_backtrace, internally use the output buffer
