https://gist.github.com/901579 is a patch against trunk that adds an
optional $limit argument to debug_backtrace() to limit the number of
frames returned.
Any thoughts?
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2011/4/4 Sebastian Bergmann sebastian@php.net:
https://gist.github.com/901579 is a patch against trunk that adds an
optional $limit argument todebug_backtrace()to limit the number of
frames returned.Any thoughts?
I would then add the same option to debug_print_backtrace().
It could also make sense to test it with a limit greater than the actual depth.
Cheers,
Patrick
I would then add the same option to
debug_print_backtrace().
Not sure I want to touch debug_print_backtrace() as it does not use
zend_fetch_debug_backtrace().
It could also make sense to test it with a limit greater than the
actual depth.
The patch has been updated with an extended test.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2011/4/5 Sebastian Bergmann sebastian@php.net:
I would then add the same option to
debug_print_backtrace().Not sure I want to touch
debug_print_backtrace()as it does not use
zend_fetch_debug_backtrace().It could also make sense to test it with a limit greater than the
actual depth.The patch has been updated with an extended test.
Don't also forget to change in the test:
[file] => /usr/local/src/php/src/trunk/Zend/tests/debug_backtrace_limit.php
to something like:
[file] => %s/Zend/tests/debug_backtrace_limit.php
Patrick
--
Patrick Allaert
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
Don't also forget to change in the test:
[file] => /usr/local/src/php/src/trunk/Zend/tests/debug_backtrace_limit.php
to something like:
[file] => %s/Zend/tests/debug_backtrace_limit.php
Accidentally reverted that, thanks. Fixed again.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2011/4/5 Sebastian Bergmann sebastian@php.net:
I would then add the same option to
debug_print_backtrace().Not sure I want to touch
debug_print_backtrace()as it does not use
zend_fetch_debug_backtrace().
They share nothing in terms of code, but well in terms of function definition:
ZEND_FE(debug_backtrace, arginfo_debug_backtrace)
ZEND_FE(debug_print_backtrace, arginfo_debug_backtrace)
[snip]
ZEND_BEGIN_ARG_INFO_EX(arginfo_debug_backtrace, 0, 0, 0)
ZEND_ARG_INFO(0, options)
ZEND_ARG_INFO(0, limit)
ZEND_END_ARG_INFO()
I think that the feature will be asked soonish if implemented for
debug_backtrace() and not for debug_print_backtrace().
I've implemented it in a gist fork: https://gist.github.com/903309.
Patrick
They share nothing in terms of code
Question is: should debug_print_backtrace() not be refactored to reuse
code from zend_fetch_debug_backtrace()? That is why did not touch it
yet.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2011/4/5 Sebastian Bergmann sebastian@php.net:
They share nothing in terms of code
Question is: should
debug_print_backtrace()not be refactored to reuse
code from zend_fetch_debug_backtrace()? That is why did not touch it
yet.
+1
I greatly share the refactoring need, I will see how this could be
done while providing as much internal API as possible so that
extension can benefit of.
I would, however, refrain from providing erroneous reflection information:
php --rf debug_print_backtrace
Function [ internal:Core function debug_print_backtrace ] {
- Parameters [2] {
Parameter #0 [ <optional> $options ]
Parameter #1 [ <optional> $limit ]
}
}
Patrick
I would, however, refrain from providing erroneous reflection information:
php --rf debug_print_backtrace
Function [internal:Core function debug_print_backtrace ] {
- Parameters [2] {
Parameter #0 [<optional> $options ]
Parameter #1 [<optional> $limit ]
}
}
I did not touch debug_print_backtrace().
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
From the ChangeLog:
2004-04-13 Zeev Suraski zeev@zend.com
* zend_builtin_functions.c:
Fix debug_backtrace to show arguments again
We need to merge code from debug_backtrace &
debug_print_backtrace at some point!
About time! ;)
I would, however, refrain from providing erroneous reflection
information:php --rf debug_print_backtrace
Function [internal:Core function debug_print_backtrace ] {
- Parameters [2] {
Parameter #0 [<optional> $options ]
Parameter #1 [<optional> $limit ]
}
}I did not touch
debug_print_backtrace().
--
Christer Edvartsen
cogo@starzinger.net
http://cogo.wordpress.com/
2011/4/5 Sebastian Bergmann sebastian@php.net:
I would, however, refrain from providing erroneous reflection information:
php --rf debug_print_backtrace
Function [internal:Core function debug_print_backtrace ] {- Parameters [2] {
Parameter #0 [<optional> $options ]
Parameter #1 [<optional> $limit ]
}
}I did not touch
debug_print_backtrace().
Yes, you did (or plan to) :)
Both debug_backtrace() and debug_print_backtrace() uses
arginfo_debug_backtrace which you modified to include the "limit"
parameter:
ZEND_BEGIN_ARG_INFO_EX(arginfo_debug_backtrace, 0, 0, 0)
ZEND_ARG_INFO(0, options)
- ZEND_ARG_INFO(0, limit)
ZEND_END_ARG_INFO()
Patrick
Both
debug_backtrace()anddebug_print_backtrace()uses
arginfo_debug_backtrace
Had not noticed that "optimization", thanks. Patch updated.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Good idea. Have you considered how Xdebug does this kind of thing (through
configuration directives, IIRC--I know it uses such things for var_dump) and
whether that might suggest a better or more future-proof approach?
Ben.
https://gist.github.com/901579 is a patch against trunk that adds an
optional $limit argument todebug_backtrace()to limit the number of
frames returned.Any thoughts?
Good idea. Have you considered how Xdebug does this kind of thing (through
configuration directives, IIRC--I know it uses such things for var_dump)
and whether that might suggest a better or more future-proof approach?
I do not want to add any INI directive.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Am 04.04.2011 17:22, schrieb Sebastian Bergmann:
Any thoughts?
Are there any objections to applying the latest version of the patch [1]
to trunk? I still think that debug_backtrace and debug_print_backtrace
are in need of refactoring but that should be kept separate, I think.
--
[1] https://gist.github.com/901579
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2011/4/8 Sebastian Bergmann sebastian@php.net:
Am 04.04.2011 17:22, schrieb Sebastian Bergmann:
Any thoughts?
Are there any objections to applying the latest version of the patch [1]
to trunk? I still think that debug_backtrace and debug_print_backtrace
are in need of refactoring but that should be kept separate, I think.
Not that this is a true blocker, but as said previously, and
considering the very few changes it introduces
(https://gist.github.com/910580), I'm not really in favor to introduce
it only in debug_bactrack() and not in debug_print_backtrace().
Both should be refactored, true, but I don't see the point to make them diverge.
I would even say that there is more benefit in terms of maintenance to
make them common now than introducing new feature to them.
Regards,
Patrick