On the SitePoint PHP blog today Troels Knak-Nielsen has posted about a lesser known feature of the popular XDebug debugging tool - function traces.

In case you haven't heard of it before, it "allows you to log all function calls, including parameters and return values to a file", to quote the manual. After playing around with it for a while, I realised that this information could be parsed and used to determine parameter types and return types of functions.

To illustrate one use for the trace results, he create a simple script that parsed them and reinjected them back into a source file as docblock comments. Included in the post is an example of its usage and the resulting comments for a simple class. It can be downloaded from github.

DevShed has posted a new tutorial today looking at one of the more useful tools a developer can add into an application - logging.

If there is no logging mechanism, then if there's a goof-up in a production environment, you have absolutely no idea what went wrong. The only thing which a support developer can do in this case is to reproduce the issue at the developer end, which sometimes work and sometimes don't.

The look at the types of logging (trace logs, audit logs and user logging/history) and create a simple class that allows flexibility for file location, priority and timstamping. Their script contains a writelog method that does all the work (including pushing it through the PEAR logging class).

Brandon Savage has posted the third part of his "Bug-Free" series to his blog today. This part focuses on the use of function traces to help narrow down the issue.

Have you ever been handed some code and told, "make it work"? If you haven't, chances are good you will some day. It's often a daunting task, especially since, as one programmer told me, "comments come when the second developer has to make changes." While this is likely bad coding practice, it's happened to me more than once.

Lucky for us, XDebug has a built-in tool that helps us evaluate code and figure out some of what is going on without spending all week reading the documentation or the code itself. It's called "function profiling."

He show how to use this profiling in your code, getting the trace results from a loop that outputs the ord() of a character (in the string "Xdebug"). He also talks about configuration changes you can make to include the parameters of the function call, the memory usage and the returns for each of the functions.

Andreas Gohr has a new blog post today that talks about a way to really get to know your code better - use XDebug to see it from the inside out.

Xdebug is a PHP extension which helps you to understand, debug and profile PHP. It can help you to find bottlenecks or give you an quick overview what happens in code you aren't familiar with, yet.

The post gives a brief overview of the installation of the extension (building a shared module) and shows how to get started with profiling an application. He talks about the cachegrind tool you can use to parse the results and the kcachegrind app that will make the results a bit more visual.

As a bonus, he also throws in a bit about function tracing - picking out each small bit of functionality in the code (the function/methods) and gathering stats for each.

On his blog today, Samisa Abeysinghe points out a library that can be used to trace the SOAP messages going back and forth between your client and server - the WSO2 Web services framework for PHP.

The Web services client class, WSClient has two methods for this, getLastRequest() and getLastResponse(). After calling the request() method of the client instance, you can call any of those methods to gain access to the messages.

Simple example code is included showing how to grab that information from the client object. If you're looking for a way to get the WSF/PHP functionality installed on your system, check out this step-by-step tutorial on using the PECL tool to create and install the packages to your PHP setup.

Continuing on from the previous part of his series, Stefan Priebsch has posted part two of his look at using XDebug over at the Zend Developer Zone.

Welcome to the second installment of our five-part series of articles on xdebug, the PHP developer's swiss army knife extension. The installation of xdebug and its basic features were covered last week. This week, we will explore the tracing feature of xdebug.

He details what tracing is and how it's helpful (no more repetitive var_dumps!) in finding issues in your code. He shows how to set up a trace log, add the code to your application to pass debugging information off to the log and how to add additional information to the log to make narrowing down the error even easier.

On the Zend Developer Zone today, Stefan Priebsch has written up an article introducing fellow developers to XDebug, a popular PHP debugging suite.

This article is the first installment of a five-part series of articles covering xdebug, a free and open source swiss army knife tool for PHP developers. xdebug is a PHP extension created by Derick Rethans, one of the PHP core developers. This week, we will show you how to install xdebug and introduce you to some of the basic features. In the subsequent parts of this article series, we will have a closer look at one of xdebug's main features, namely tracing, profiling, debugging, and code coverage.

In this first installment, he looks at installing the software (both on a unix-based system and on a Windows box) and how to turn it on to work with your web server. He also mentions some of the error output options including the "new and improved" var_dump call and the stack trace method to help you locate exactly where in the code the error's hidden.

Tony Freixas has posted a new article covering his thoughts on high-performance debugging with PHP5:

In this article, I will show you how to use PHP 5 input filters to support debug, trace and assert statements so that a one-line change disables these statements and restores your script to full production performance.

He makes a custom solution, a simple method for just outputting simple debug statements via his own custom debugging classes - thDebug, theTrace and thAssert. He wraps all of these in a thDebugManager class to make them all play nice together.

With these in place, he moves on to the real key to the debugger, using the input filter extension that comes with PHP5. He makes a thAbstractStreamFilter abstract class to base the filtering on and, using this interface, makes his thDebugFilter class to handle the various debugging outputs. He uses the __autoload functionality to load it correctly into each page that needs it.

With all of the good news they've posted about the mysqlnd driver, the developers behind the Internet Super Hero blog know that there will be bugs that come up in the driver. So, they've addressed the right way to find and deal with these issues in a new blog entry.

he bad news: mysqlnd might have bugs. How to report and debug these bugs - using mysqli_debug() - is subject of this posting.

They step you through the process for finding out what's causing the problems (internal versus external debugging) and how to make client traces with the mysqi extension to make it even easier for the developers to track down the problem. They also suggest a few things to send along with your bug report - like the PHP code calling it or the SQL you're using to select/update/insert/delete the data from your database.

Bothered by the ugly way Xdebug stack traces were turing out, Derick Rethans has created a script to fix that.

I've always been annoyed by the way how Xdebug's stack traces looked liked. So I spend some time on making them look better. I will show the differences according to the following script.

The simple script takes the output and adds a bit of formatting, stripping down the information to make it a bit more clear. Check out the before and after shots to see the difference.