Derick Rethans - tag: xdebug

Available for PHP Extension Writing

Mon, 15 Mar 2010 12:28:00 +0000

Available for PHP Extension Writing

Monday, March 15th 2010, 12:28 GMT

Slightly more than a month ago I left my job as team-lead of eZ Components at eZ Systems behind, to focus on something new. During the past month I've been contemplating about what to do next and realized that I do not want to take on a new full-time position right away. Instead I will be available to work on (custom) PHP extensions and internals related issues. Extensions are a great way around PHP's limitations and performance issues.

As first project I am working on a "QuickHash" extension for StumbleUpon. This extension circumvents PHP's hefty memory (and performance) overhead by providing more specific data structures. The extension currently implements integer sets and integer to integer hashes. I am now adding integer to string hashes and string to integer hashes. The QuickHash extension will be released under the PHP Licence and I will dedicate another post to it later.

If, like StumbleUpon, you are also interested in having work done on PHP or a specific extensions feel free to contact me. I'd be happy to discuss things with you.

Xdebug 2.1.0beta3 released

Sat, 27 Feb 2010 23:57:00 +0000

Xdebug 2.1.0beta3 released

Europe/London

Saturday, February 27th 2010, 23:57 GMT

I've just released Xdebug 2.1.0beta3 which includes a few crash bugs as well as the issue that headers sent from PHP scripts are not actually set.

You can find the full changelog here and get the latest version from the download page.

More source analysis with VLD

Fri, 19 Feb 2010 11:27:00 +0000

More source analysis with VLD

London, UK

Friday, February 19th 2010, 11:27 GMT

VLD is a tool that I started working on years ago to visualise the opcode arrays in PHP. Opcode arrays are what PHP's compiler generates from your source code and can be compared to assembler code that is generated by a C compiler. Instead of it being directly executed by the CPU, it is instead executed by PHP's interpreter.

Over the years I've been adding some functionality, also aided by Ilia and some others, to show more information. For example Ilia has added a more verbose dumping format for opcodes (through the vld.verbosity setting) whereas I have added routines to find out which ops in oparrays can never be reached. A very simple example of the latter is shown here:

If we run the above through VLD with php -dvld.active=1 test.php, you'll see the following output (I removed the part about the script body itself):

Function test:
filename:       /tmp/test1.php
function name:  test
number of ops:  9
compiled vars:  none
line     # *  op           fetch  ext  return  operands
---------------------------------------------------------
   2     0  >   EXT_NOP
   4     1      EXT_STMT
         2      ECHO                           'Hello%21%0A'
   5     3      EXT_STMT
         4    > RETURN                         true
   7     5*     EXT_STMT
         6*     ECHO                           'This+will+not+be+executed.%0A'
   8     7*     EXT_STMT
         8*   > RETURN                         null

End of function test.

Every opcode that has a * after the number (like in 5*) is code that can not be reached, and can possibly be eliminated from the oparrays in an optimiser.

The dead code analysis routines have also made their way into Xdebug which uses them for the code coverage functionality to highlight dead code. This mostly makes sense if you are running your code coverage together with unit tests such as you can do with PHPUnit.

Recently I've been working on some new functionality to visualise all the code paths that make up each function. These new routines sit on top of the routines that do dead code analysis. Every branch instruction (such as if, but also for and foreach) is analysed and a list of branches is created. Each branch contains information about the line on which the branch starts, the starting and ending opcode numbers that belong to the branch, as well as to which other branches this branch can jump to. There can be either no linked branches (when for example a return or throw statement is found), one linked branch (for an unconditional jump) or two linked branches (on a branch instruction). However, you need to be aware that internally, PHP's opcode don't always reflect the source code exactly.

Once all the branches and their links are found, another algorithm runs to figure out which paths can be created out of all the branches. It is best to illustrate this with an example. So let us look at the following script:

In this script we have a for-loop with a nested if construct. When we run this script through VLD (with php -dvld.verbosity=0 -dvld.dump_paths=1 -dvld.active=1 test2.php) we get the following output (again, only the test() function and with some white space modifications):

Function test:
filename:       /tmp/test2.php
function name:  test
number of ops:  22
compiled vars:  !0 = $i
line     # *  op             fetch  ext  return  operands
-----------------------------------------------------------
   2     0  >   EXT_NOP
   4     1      EXT_STMT
         2      ASSIGN                             !0, 0
         3  >   IS_SMALLER                 ~1      !0, 10
         4      EXT_STMT
         5    > JMPZNZ                  9          ~1, ->18
         6  >   POST_INC                   ~2      !0
         7      FREE                               ~2
         8    > JMP                                ->3
   6     9  >   EXT_STMT
        10      IS_SMALLER                 ~3      !0, 5
   7    11    > JMPZ                               ~3, ->15
   8    12  >   EXT_STMT
        13      ECHO                               '-'
   9    14    > JMP                                ->17
  12    15  >   EXT_STMT
        16      ECHO                               '%2B'
  14    17  > > JMP                                ->6
  15    18  >   EXT_STMT
        19      ECHO                               '%0A'
  16    20      EXT_STMT
        21    > RETURN                             null

branch: #  0; line:  2- 4; sop:  0; eop:  2; out1:   3
branch: #  3; line:  4- 4; sop:  3; eop:  5; out1:  18; out2:   9
branch: #  6; line:  4- 4; sop:  6; eop:  8; out1:   3
branch: #  9; line:  6- 7; sop:  9; eop: 11; out1:  12; out2:  15
branch: # 12; line:  8- 9; sop: 12; eop: 14; out1:  17
branch: # 15; line: 12-14; sop: 15; eop: 16; out1:  17
branch: # 17; line: 14-14; sop: 17; eop: 17; out1:   6
branch: # 18; line: 15-16; sop: 18; eop: 21
path #1: 0, 3, 18,
path #2: 0, 3, 9, 12, 17, 6, 3, 18,
path #3: 0, 3, 9, 15, 17, 6, 3, 18,
End of function test.

This dump consists of a few different parts. First of all we can see some basic information containing the name, the number of ops (22) and the compiled variables. The second part is a dump of all the opcodes that make up this function. The last part contains information about all the branches and the possible paths. This information is a bit hard to visualize in its textual form, so I've also added some code that dumps this information to a file format that the GraphViz tool "dot" can use to create a pretty graph. For this we re-run the previous PHP invocation as php -dvld.dump_paths=1 -dvld.verbosity=0 -dvld.save_paths=1 -dvld.active=1 test2.php. This creates the file /tmp/paths.dot that "dot" can use. If we run dot -Tpng /tmp/paths.dot > /tmp/paths.png we end up with the following picture:

If we put this graph next to the code, we can explain how this works. Every branch is named by the number of the first opcode in that branch:

op #1 is the assignment of $i in line 4.
op #3 is the loop test in line 4. If the condition doesn't match, we jump to op #18 on line 16 that echos the newline.
op #9 is the if condition on line 6.
op #12 is when the if condition returns true and
op #15 is when the if condition returns false.
op #17 sits behind both op #12 and op #15 and makes sure there is a jump to the counting expression in #op 6.
op #6 is the post increment operation on line 4 which will then again be followed by op #3 to check whether the end of the loop has been reached.

This is of course a very simple example, but it also works for (multiple) classes and functions in a file. You just need to make sure to tell VLD that you don't want the code executed as the output could be very large. You can use the vld.execute=0 php.ini setting for that.

I hope this new functionality can spread some light on how loops etc. work in PHP. In order to play with the code, you need to check-out VLD from my SVN with svn co svn://svn.xdebug.org/svn/php/vld/trunk vld. You can also view the code on-line at http://svn.xdebug.org/cgi-bin/viewvc.cgi/vld/trunk/?root=php. Look out for a new release coming soon!

Thu, 18 Mar 2010 23:24:04 +0000

New Xdebug browser extensions

Wed, 17 Feb 2010 12:33:00 +0000

New Xdebug browser extensions

London, UK

Wednesday, February 17th 2010, 12:33 GMT

Years ago I wrote about a Firefox extension that allows you to start an Xdebug debugging session by clicking on an icon in Firefox' status bar. For some unexplained reason, this extension is no longer available through Firefox' addon-site. Although I have a copy at http://xdebug.org/files/xdebug_helper-0.3.1-fx.xpi for archival purposes, there are now a few other browser extensions that do the same thing.

easy Xdebug

easy Xdebug is an extension that serves as a replacement for the now unavailable Xdebug helper extension. It's written by Brecht Vanhaesebrouck of eLime. The extension was originally tested with Netbeans but it also seems to work fine with Komodo.

Xdebug enabler

Xdebug enabler is an extension for Google's Chrome browser. It "allows you to enable and disable triggering Xdebug from with in Chrome. Useful if you are a web developer using an IDE that supports Xdebug like Eclipse with PDT." It's written by 'remailednet' and available through the Google Chrome Extensions website.

JavaScript 'enabler'

I also ran across a blog post by 'Caleb G' from HigherVisibility. Instead of making an extension for a specific browser, he outlines two JavaScript bookmarklets that allow you to start and stop an Xdebug debugging session.

Update: The "Xdebug enabler" Chrome Extension seems to have some issues. There is now also an alternative Chrome Extension called Xdebug helper that integrates quite a bit better. You can find it at its Google Chrome Extension page.

Xdebug 2.1.0beta2 released

Wed, 03 Feb 2010 18:51:00 +0000

Xdebug 2.1.0beta2 released

Dieren, the Netherlands

Wednesday, February 3rd 2010, 18:51 GMT

I've just released Xdebug 2.1.0beta2 which features a few small bug fixes only. With this release the Windows 5.3/VC6 binaries also return.

One of the bug fixes is in a new feature that allows you to configure that the debugger should connect back to the IDE running on the machine that initiated the HTTP request. This feature, that originally was contributed by Lucas Nealan and Brian Shire of Facebook, allows more easy use of multiple IDEs (users) working on the same code base. In order to enable this, set xdebug.remote_connect_back to 1. See the documentation for more information.

Of course, this feature should only be enabled if nobody besides authorized developers can access the machine on which the xdebug.remote_connect_back callback feature has been enabled. Instead of enabling this setting, you can also support multiple developers through the proxy functionality that the DBGp protocol supports. For more information on that, see Debugging with multiple users.

You can find the full changelog here and get the latest version from the download page.

Speaking at conferences in spring 2010

Tue, 26 Jan 2010 14:22:00 +0000

Speaking at conferences in spring 2010

London, UK

Tuesday, January 26th 2010, 14:22 GMT

In the next few months, I will be speaking at the following conferences:

PHPBenelux Conference 2010 is the first annual conference by the PHPBenelux usergroup. It is organized in Antwerp on Saturday January 30th. I will be giving a keynote titled "The PHP Universe".

PHP UK Conference is PHP London's fifth annual conference and held on Friday February 26th at the Business Design Centre. I will be talking on PHP on the D-BUS.

ConFoo (formerly PHP Québec) is the first edition of the Confoo.ca Conference. From March 10th to 12th 2010, international experts in Java, .Net, PHP, Python and Ruby will present solutions for developers and project managers the Hilton Bonaventure Hotel, located in downtown Montréal. I will be talking on Advanced Date/Time handling with PHP.

Hope to see you there!

Obtaining the next month in PHP

Fri, 08 Jan 2010 09:13:00 +0000

Obtaining the next month in PHP

London, UK

Friday, January 8th 2010, 09:13 GMT

Over and over again PHP users complain that next month in PHP's date-string parser doesn't go to the next month, but instead skips to the one after next month; like in the following example:

modify( 'next month' );
echo $d->format( 'F' ), "\n";
?>

The output of the little script will be March. March obviously doesn't follow January as February is in between. However, the current behavior is correct. The following happens internally:

next month increases the month number (originally 1) by one. This makes the date 2010-02-31.
The second month (February) only has 28 days in 2010, so PHP auto-corrects this by just continuing to count days from February 1st. You then end up at March 3rd.
The formatting strips off the year and day, resulting in the output March.

This can easily be seen when echoing the date with a full date format, which will output March 3rd, 2010:

format( 'F jS, Y' ), "\n";
?>

To obtain the correct behavior, you can use some of PHP 5.3's new functionality that introduces the relative time stanza first day of. This stanza can be used in combination with next month, fifth month or +8 months to go to the first day of the specified month. Instead of next month from the previous example, we use first day of next month here:

modify( 'first day of next month' );
echo $d->format( 'F' ), "\n";
?>

This script will correctly output February. The following things happen when PHP processes this first day of next month stanza:

next month increases the month number (originally 1) by one. This makes the date 2010-02-31.
first day of sets the day number to 1, resulting in the date 2010-02-01.
The formatting strips off the year and day, resulting in the output February.

Besides first day of, there is an equivalent last day of to go to the last day of a month. The following example demonstrates this:

modify( 'last day of next month' );
echo $d->format( 'F jS, Y' ), "\n";
?>

This outputs February 28th, 2010. Internally the following happens:

next month increases the month number (originally 1) by one. This makes the date 2010-02-08.
last day of increases the month number by one, and sets the day number to 0, resulting in the date 2010-03-00.
PHP then auto-corrects the invalid day number 0 by removing one from the month and skipping to the last day of that month, resulting in 2010-02-28.

I hope this clears up some of the behaviour of PHP's Date/Time handling. For more information on Date/Time Programming with PHP, please refer to my book "php|architect's Guide to Date and Time Programming" that is available through Amazon.

Xdebug 2.1.0beta1 released

Sun, 03 Jan 2010 02:08:00 +0000

Xdebug 2.1.0beta1 released

London, UK

Sunday, January 3rd 2010, 02:08 GMT

It has been two years since I released Xdebug 2.0.0. Since then I've added many new features to Xdebug. For some of those new features you can find a little description below—I will write more about these, and other features later.

Besides the features, I also fixed a whole array of bugs and Xdebug 2.1.0 comes with PHP 5.3 support. From now on I will not be supporting any PHP versions less than PHP 5.1 anymore. But now on to the descriptions:

Header Setting Interception

All functions that set HTTP headers such as with header() and setcookie() are now intercepted by Xdebug. The intercepted headers are stored internally in an array that can be retrieved by calling the xdebug_get_headers() function. This is very useful in cases where you need to test certain functionality that sets headers somewhere deep in code. This function is also used in eZ Components' test suite to test whether the correct HTTP headers are set in the MvcTools component.

Variable Assignment Tracing

Allows you to record changes to variables in scripts to trace files. I've already written more about it in Variable tracing with Xdebug.

"Scream" Support

The scream PECL extension disables the @ (shut-up) operator to actually see all notices, warnings and errors that PHP generates. The scream extension's functionality have been duplicated as Xdebug's xdebug.scream php.ini setting. Why disabling the @-operator is a good thing, I've already outlined in Five reasons why the shut-op operator (@) should be avoided.

What's Next?

There are still a few bugs left that need some attention, but this first beta should have most of them fixed. Please test the beta as much as you can and provide feedback in the issue tracker. After this initial beta it is like that one more more betas will follow before I prepare a release candidate. Xdebug 2.1.0beta1 can be obtained through the Xdebug website and a full changelog is also available. You can also follow Xdebug on twitter to be kept up-to-date with the latest developments.

PHP Development Environment 2.0

Thu, 31 Dec 2009 02:26:00 +0000

PHP Development Environment 2.0

London, UK

Thursday, December 31st 2009, 02:26 UTC

When moving the Xdebug website and my own website to a new server I had to pick a web server to serve the pages through PHP. Up to then I was still using Apache 1.3 with zero intentions to ever upgrade to any later version. I'd heard a lot about lighttpd and decided to give that a try—yes, that meant something that I didn't really know to well was going to run in a production environment. Unlike Apache, with lighttpd PHP doesn't run as a module, but instead you run it out of process with something called FastCGI.

On my development machine I was also running Apache 1.3 with PHP as static module embedded. If I want to test something with a different PHP version, I would start a different Apache daemon. When I had a quick look the other day, I found that I had about 28 different binaries named httpd-{Apache version}-{PHP version} ranging from PHP 4.1.2 to 6.0dev. Some of those I hadn't used for years.

All my PHP installations were installed with the same prefix (/usr/local), where the last built PHP version was available as php and additional versions as php-{version}. An annoyance with this is, is that I had to run make install in one of the PHP source directories before I could compile extensions against a different PHP version than the latest installed one. This combined with the enormous amount of httpds and the inability to run multiple versions of PHP at the same time prompted me to come up with something better: PHP Development Environment 2.0.

Multiple PHP Installations

The first thing I wanted to do was to make sure that each minor PHP version (5.1.x, 5.2.x, 5.3.x and 6.0.x) could be installed alongside each other, and that I could compile extensions to all of them without having to re-run make install. I did this by specifying --prefix=/usr/local/php/{PHP version} to the PHP configure call. At the same time, I also removed the --with-apache configure option and for PHP 5.1 and PHP 5.2 I added the --enable-fastcgi option which is default enabled for PHP 5.3 and PHP 6.0. The initial section of the configure invocation now looks like for the PHP 5.2 build:

./configure --prefix=/usr/local/php/5.2dev --enable-fastcgi \
  --with-gd  ...more configure options here...

Although /usr/local/bin is usually in the path, but /usr/local/php/5.2dev/bin is definitely not. The initial goal was to be able to easily switch between different PHP versions, so I added a snippet to my .bashrc that sets the correct PATH environment variable depending on the selected PHP version:

function pe () {
  version=$1
  shift

  if [ "$#" == "0" ]; then
    export PATH=/usr/local/php/${version}/bin:/usr/local/bin:/usr/bin:/bin
  else
    PATH=/usr/local/php/${version}/bin:$PATH $@
  fi
}

This bash function is then evoked like pe 5.3dev to set the path in such a way that php runs the PHP 5.3 binary, as well as additional tools such as pear, phpize (required to build extensions) and php-config. If you forget to call the pe function, then when running php you will encounter the warning bash: php: command not found. You could pick a default version if you wanted, but I prefer that I always have to be explicit about which PHP version I pick. Multiple install paths makes it easier to maintain multiple PHP installs, but it also means that you have to install tools such as PHP Unit for each of the installations.

Setting up Lighttpd

Now that I had multiple PHP installations, I could move on to setting up lighttpd. As I have mentioned, I never used lighttpd before and decided to take the easy way by installing it with apt-get install lighttpd. PHP works through the FastCGI interface with lighttpd which you can enable with lighttpd-enable-mod cgi fastcgi simple-vhost (I also enabled CGI and simple VHOSTing).

To enable PHP as FastCGI server, and to be able to run multiple versions at the same time, I modified the /etc/lighttpd/conf-enabled/10-fastcgi.conf configuration file. Find my annotated version below:

## Enable the FastCGI module.
server.modules   += ( "mod_fastcgi" )

Next we start an FastCGI server for the default PHP version (5.3) on the default port (80) by enabling it in the global scope:

fastcgi.server    = ( ".php" =>
  ((
    ## The path to the PHP-CGI executable
    "bin-path" => "/usr/local/php/5.3dev/bin/php-cgi",

    ## The listening socket that allows lighttpd to talk
    ## to the PHP FastCGI process. This needs to be
    ## different for each fastcgi.server definition.
    "socket" => "/tmp/php80.socket",

    ## Configure the number of parent processes that are
    ## spawned by lighttpd (max-procs) and configure how
    ## many many workers should be started (4) and the
    ## maximum number of requests that they can process
    ## before they get recycled (10000).
    "max-procs" => 1,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),

    ## configure additional bits
    "bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),
    "broken-scriptfilename" => "enable"
    "idle-timeout" => 20,
  ))
)

Now tell lighttpd to also listen on port 8502. And in case requests come in over this port, use the defined FastCGI server for *.php. In this case we configure PHP 5.2. Similarily you can also define a block for PHP 5.1 (on a suggested port 8501) and PHP 6.0:

$SERVER["socket"] == ":8502" {
  fastcgi.server    = ( ".php" =>
    ((
      "bin-path" => "/usr/local/php/5.2dev/bin/php-cgi",
      "socket" => "/tmp/php8052.socket",
      "max-procs" => 1,
      "idle-timeout" => 20,
      "bin-environment" => (
        "PHP_FCGI_CHILDREN" => "4",
        "PHP_FCGI_MAX_REQUESTS" => "10000"
      ),
      "bin-copy-environment" => (
        "PATH", "SHELL", "USER"
      ),
      "broken-scriptfilename" => "enable"
    ))
  )
}

Tell lighttpd to also listen on port 8502. Because we're not overriding the fastcgi.server configuration from the global configuration (the bit were we set-up PHP 5.3 in the first few lines of the file), it will reuse this fastcgi.server configuration enabling requests for .php files coming in on port 80 or 8503 to be processed by the globally configured FastCGI server:

$SERVER["socket"] == ":8503" {
# Just some dummy text because lighttpd doesn't allow
# empty definitions.
}

With the configuration made, you only have to restart lighttpd with /etc/init.d/lighttpd force-reload and PHP is ready to go on multiple ports with different PHP versions.

Xdebug moved to a new server

Fri, 27 Nov 2009 14:42:00 +0000

Xdebug moved to a new server

London, UK

Friday, November 27th 2009, 14:42 GMT

Xdebug 's CVS server was previously hosted at eZ Systems' office, but as I am leaving soon I needed to move this to a different server. At the same time, I decided to also convert from CVS to SVN. So from now on, there is no more cvs.xdebug.org, but just a svn.xdebug.org. This SVN server doesn't only host Xdebug, but also some of my other projects, such as VLD (opcode dumper to aid PHP engine development), the DBGp specs (debugger protocol as used by Xdebug and ActiveState's debuggers) and my OpenMoko perversions and projects.

Xdebug can now be checked out from SVN with:

svn co svn://svn.xdebug.org/svn/xdebug/xdebug/trunk xdebug

All other Xdebug services (mailinglists, web, e-mail and the bug system) moved to the same server as well. Just be aware that DNS servers might still need updating when you try to access the new services.

Xdebug and tracing memory usage

Fri, 13 Nov 2009 11:59:00 +0000

Xdebug and tracing memory usage

London, UK

Friday, November 13th 2009, 11:59 GMT

Recently people started to ask me how to use Xdebug to figure out which parts of applications use a lot of memory. Traditionally this was part of Xdebug's profiling functionality. Unfortunately the cachegrind format didn't fit this so well, and because it returned incorrect data I removed this functionality from the profiler. However, there is other functionality in Xdebug that does provide the correct data: the function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it. With the last two numbers it's rather trivial to write a script to figure out which functions/methods increase the memory usage a lot. Of course, nobody had written a script yet to do anything with this information

As part of my preparations for my Xdebug talk at IPC next week, I now have written such a script. The script parses the tab-separated function trace files and aggregates all the information by function name. You can sort the output on a few different keys: time-own, memory-own, time-inclusive, memory-inclusive and calls. You can also configure how many elements it will show. As an example here is some output from a trace of one of the presentation system's PHP scripts:

$ php tracefile-analyser.php trace.2043925204.xt memory-own 20

parsing...
Done.
Showing the 20 most costly calls sorted by 'memory-own'.
                                               Inclusive        Own
function                               #calls  time     memory  time     memory
-------------------------------------------------------------------------------
require_once                                9  0.0541  4595160  0.0277  2548104
{main}                                      1  0.0600  2906032  0.0034   249744
fread                                       4  0.0001    33296  0.0001    33296
session_start                               1  0.0002    31824  0.0002    31824
XML_Presentation->startHandler             38  0.0073    36360  0.0035    18424
_pres_slide->_pres_slide                   27  0.0009    10152  0.0009    10152
_presentation->_presentation                1  0.0001     7912  0.0001     7912
strtolower                                 67  0.0017     6456  0.0017     6456
compact                                     1  0.0000     4832  0.0000     4832
each                                        5  0.0001     4320  0.0001     4320
XML_Presentation->endHandler               38  0.0014     3800  0.0014     3960
_slide->_slide                              1  0.0001     3896  0.0001     3896
XML_Slide->startHandler                     4  0.0009    10800  0.0004     3736
_image->_image                              1  0.0000     3040  0.0000     3040
fopen                                       2  0.0001     2816  0.0001     2816
getimagesize                                1  0.0001     2296  0.0001     2296
display->display                            1  0.0001     2120  0.0001     2120
explode                                     2  0.0001     2120  0.0001     2120
xml_parser_create                           2  0.0001     1680  0.0001     1680
XML_Parser->_initHandlers                   2  0.0011     1600  0.0005     1360

The script is available from SVN by running:

svn co svn://svn.xdebug.org:/svn/xdebug/xdebug/trunk/contrib xdebug/contrib

The script to run is then "tracefile-analyser.php" from inside the "xdebug/contrib" directory.

Update 2009-12-28: Changed the CVS instructions to the new SVN instructions.

CodeWorks and ZendCon

Mon, 19 Oct 2009 04:46:00 +0000

CodeWorks and ZendCon

London, UK

Monday, October 19th 2009, 05:46 BST

CodeWorks was a blast, I recorded a few talks that I will be publishing through Vimeo. As teaser I have a recording of Scott MacVicar's PECL picks talk. I also have recordings of Brian Moon's Memcached talk, Chris Shiflett's Security-Centered Design talk and Sharon Levy's Web-Based Retrieval Demystified talk. With all the other random video material I am creating a compilation as well, but that will have to wait a bit more.

At the moment I am on my way to San Jose where I will speak on Xdebug and PHP's DateTime support. Xdebug 2.1 is now feature complete, and I will be working on getting all the open bugs resolved. A release before the end of the year seems likely.

Autumn Plans

Mon, 14 Sep 2009 12:26:00 +0000

Autumn Plans

London, UK

Monday, September 14th 2009, 13:26 BST

I've been missing-in-action on my own blog for some time. Moving to London does that to you. Anyway, I've not been idle in the meanwhile at all, and been working on some cool side-projects. First of all I've been adding some features to Xdebug . Xdebug is now slow reaching beta-status for the 2.1 release. New feature will include proper PHP 5.3 support, variable tracing, "scream" support and other minor features.

Besides Xdebug I've also been hacking on PHP-GTK applications for my phone . The major new thing that I have now is a PHP-GTK twitter client that works like I want it... and I even use it on my desktop instead of all the other stuff that's out there. I will soon be publishing this client in my CVS repository.

Now that the conference season is starting again I'm working on improving several talks, as well as rewriting some parts for them. The first conference that I will be speaking at, are part of "Marco's Crazy PHP Conference Tour" aka CodeWorks . I'll be giving three different talks here, one on "Debugging with Xdebug ", one on PHP's DateTime support and one on "Improving your development process" where I'll be talking about Test-Driven Development and other tricks associated by running a project. As CodeWorks is a bit like a rock-star tour, I'll be keeping a video blog of it somewhere on the intertubes.

pfcongrez, P2P Конференция, php|tek, PHP Vikinger, DPC and eZ Conference and Awards

Thu, 09 Apr 2009 23:45:00 +0000

pfcongrez, P2P Конференция, php|tek, PHP Vikinger, DPC and eZ Conference and Awards

London, UK

Friday, April 10th 2009, 01:45 CEST

The above mentioned conferences all have one thing in common: I'll be speaking. At the first conference, pfcongrez I will be talking on implementing Test Driven Development as a model for software development. A modified version of this talk I will also give at the next conference, P2P Конференция (P2P Conference) in Bulgaria. At this same conference I will be talking on using PHP as development language for GSM based applications on mobile computing platforms running Linux, where I will use the pecl/dbus extension to talk to the interface framework available on the OpenMoko platform. This same talk I will also give at DPC in Amsterdam. In between however I will go to Chicago to speak at php|tek on search technologies in my "Haystacks and Needles" talk and on simple architecture in my KISS talk. Before DPC I will also go to Leuven for PHP Vikinger , an unconference that I'll be organizing for the 3rd time. This year it is no longer in Norway, but instead we moved to Leuven in Belgium. It is also de-coupled from the eZ Conference and Awards which will be in Paris.