The odd bit

Once is an accident, twice is a coincidence, three times is an enemy action.

The odd bit - Once is an accident, twice is a coincidence, three times is an enemy action.

Upgrade time

My current PC will be three years old in two weeks time. That’s one year older than my previous personal best. I still have my previous PC and it’s still in use, but I only used it for two years as primary system.

My current system still has quite decent specs, apart from the graphics card: P4 3.06 GHz (Northwood core), ATI Radeon 9700 Pro, 1GB DDR RAM, 120GB HD, DVD+/-RW, … But everything is slower than today’s equipment. The CPU’s FSB is running at 533 MHz, the memory is PC2100, etc etc.

I’m currently aiming at these specs for the new system:

  • Intel P4 940 (dual core 3.2 GHz 64-bit with 2x 2MB L2 cache)
  • ATI Radeon X1900XT(X) with 512MB video memory
  • 2 GB DDR2 system memory
  • 200 GB or larger SATA2 hard disk
  • Dual layer DVD writer

If everything goes fine, I’ll buy all components within two weeks and experience a power boost :)

MySQL now uses slots

Gentoo Portage now contains new MySQL ebuilds that use slots. Slots are portage’s mechanism to allow different versions of a package to be installed at the same time. Without slots, you’re restricted to one version. The best known examples of slotted packages are KDE and the various kernel packages. To summarise all of this: with the new ebuilds you can have e.g. MySQL 4.1, 5.0 and 5.1 installed at the same time.

Moving to the new ebuilds, which are no longer hard masked but are still in the unstable branch (~x86 in my case), does require a bit of work. But don’t panic! The Gentoo devs have written a migration guide to ease the switch for you.

I’m currently in the process of switching to the 5.0.18 slotted version…
The switch to 5.0.18-r30 is now complete :-)

The lurking dangers of references in PHP

A while ago, PHP 4.4 was released to address a rather weird memory corruption problem in the PHP 4.3 series. The problem was related to returning by reference. The bug allowed statements to be returned by reference while it should only be possible to return variables by reference.

To provide users with a PHP 4.4 compatible version of eZ publish, eZ systems released version 3.7 which is a clone of version 3.6 with the reference fixes added to it. Simply changing the 3.6 codebase was not an option because what was needed in 3.6 to go around the memory corruption would no longer be valid in PHP 4.4. The reverse was also true, what was needed in the PHP 4.4 version would trigger the memory corruption in 3.6.

Unfortunately, the problem doesn’t stop there. There are also a lot of extensions for eZ publish. Some of them don’t need a change while others need to be updated to be PHP 4.4 compatible. I’ll give an example…

If you happen to use e.g. the eZXML library in your extension, you’re among the lucky ones who need to change some code for the newer version ;-). A great example is eZDOMDocument::createElementNode(). That function returns by reference in eZ publish versions prior to version 3.6 and returns by value from 3.7 onwards. This means your code for 3.6 should look like ($doc is an instance of the eZDOMDocument class) (code A):

$exampleNode =& $doc->createElementNode( ‘example’ );

And for 3.7 (code B):

$exampleNode = $doc->createElementNode( ‘example’ );

The difference is pretty small if you look at it, but it could be rather significant. If you use code A for both versions (3.6 and 3.7) it should not be that significant. It’s how it should be for 3.6, while the reference assignment should be ignored in 3.7 because the function returns by value. However, you’re not following the eZXML API which could have an unknown impact now or in later PHP versions and it’s not a good coding practice.
One could also suggest to use code B for both versions, but then things get worse. You’re alright in version 3.7 (or any PHP 4.4 version for that matter), but you’re simply ignoring the return by reference in 3.6 which means you’re back at the initial problem: possible memory corruption. And just to be sure, I asked Derick Rethans (PHP and eZ publish developer) if ignoring a return by reference would be a good idea in PHP 4.3. His response:

It’s indeed how it not should be done. Returning by reference from a function, while not assigning the result by reference will not work (ofcourse, as the reference is ignore). As far as I can remember it is exactly this case that caused the memory corruptions in PHP 4.3.x.

So be careful when switching to the new code because you can’t predict when the memory corruption bug will appear, but count yourself lucky if you don’t encounter it. I have encountered the bug before and it absolutely makes no sense when you spot the problem.

Note: 3.6 in this post refers to eZ publish version 3.6 which in turn refers to the eZ publish codebase for PHP 4.3. 3.7 in the post refers to eZ publish version 3.7 which should be read as the eZ publish codebase for PHP 4.4.