In the latest post to the SitePoint PHP blog Vova Feldman shows you how to create an integer from a hash string that's both 64 bit and unique each time it's generated.

PHP provides the popular md5() hash function out of the box, which returns 32 a hex character string. It’s a great way to generate a fingerprint for any arbitrary length string. But what if you need to generate an integer fingerprint out of a URL?

He describes the real-world situation he was facing - a rating widget that needed a randomized integer based on the page using it - and the two "sub-challenges" that make it up: url canonization and the string to unique 64 bit problem. He tackles each problem and shares code snippets showing the process and how it can be put to use. He also includes some interesting metrics at the end of the post showing the level of hash collisions (hint, it's a very low number).

On the SitePoint PHP blog today they pose a question to all PHP developers out there - is your application affected by the Y2K38 bug?

I don't want to be too alarmist, but try running the [given] PHP code on your system. [...] With luck, you'll see "Wednesday 1 February 2040 00:00" displayed in your browser. If you're seeing a date in the late 60's or early 70's, your PHP application may be at risk from the Y2K38 bug!

The bug, caused by a 32-bit operating system, can be helped by running the application on a 64-bit platform (it's due to the limitation of integer size), but there is another option - the DateTime class that handles dates and times differently than the just using the local time settings.

Chris Jones has a new post to his blog today showing how to use the latest 32-bit OCI8 (Oracle) drivers in a 64-bit Windows environment (like on Windows 7 or similar OSes).

The world migration from 32-bit to 64-bit operating systems is gaining pace. However I've seen a couple of customers having difficulty with the PHP OCI8 extension and Oracle DB on Windows 64-bit platforms. The errors vary depending how PHP is run. They may appear in the Apache or PHP log. [...] Other than IIS permission issues a common cause seems to be trying to use PHP with libraries from an Oracle 64-bit database on the same machine. There is currently no 64-bit version of PHP on http://php.net/ so there is a library mismatch.

The solution is to install the Oracle Instant Client, move a few files around, edit your path and you should be good to go.

Carson McDonald has just released a guide for getting the highly-anticipated release from Facebook, HipHop PHP, up and running on Fedora 12 systems (both 32 and 64 bit flavors).

The first thing to note is that they are only supporting 64 bit systems officially. [...] I'm going to assume at first that you are using a 64 bit system and then end with what you need if you are still using a 32 bit system.

He used an EC2 instance to substitute for a local 64 bit machine, but it works all the same. He includes the commands (package changes) to get the machine where it needs to be to perform the HipHop install and how to get the latest HipHop source from github. Most of the install is handled via packages, but you will need to get into the HipHop source a bit and change a few things for this issue. With everything in place you can run a cmake/make on the source and wait for the resulting binary to be created.

He's condensed down this whole process into one script for those that want a simpler solution.

On the O'Reilly ONLamp blog Todd Ogasawara points out a few things that Windows users should watch out for with the upcoming PHP 5.3 release.

PHP 5.3.0 is only in its first alpha release. But, if you run PHP in Microsoft Windows, you should talk a look at the release notes for Windows binaries.

Among the changes are things like the drop of support for Windows versions less than Win2000, the changeover for compiling needs (VC6 versus the newer VC9) and that 64-bit binaries will be provided as well as the normal 32-bit (on a trial basis).

In a recent post to his blog Tony Bibbs shares his experience with getting the most recent release (PHP 5.3 alpha) of PHP up and working on his MacBook.

If there is anything you should gleam from this article for future reference, Leopard comes with a 64bit Apache installation.

He points out this fact because, if you go and build it as per the normal install instructions, it will toss a "wrong architecture" error. He points out a blog post from Marc Liyanage that helped him understand a bit better. His fix was to run Apache as 32 bit instead of trying to get PHP to compile up to its 64 bit standards. He even includes the two commands you'll need to change Apache over to run this way.

Christian Stocker points out a blog post from Tobias Ebnother showing how to set up a native apache instance on Leopard (OS X) with a 64 bit PHP included.

With massive! help from Marc Ammann I was able to build a PHP Binary that loads with the Leopard shipped Apache.

His method replaces the standard iconv file with a custom built one (based on this source) prior to compiling. Then, in his configure, he sets certain flags, specifically the "arch x86_64" one, to get it to recognize the new setup.

Christian Stocker points out a blog post from Tobias Ebnother showing how to set up a native apache instance on Leopard (OS X) with a 64 bit PHP included.

With massive! help from Marc Ammann I was able to build a PHP Binary that loads with the Leopard shipped Apache.

His method replaces the standard iconv file with a custom built one (based on this source) prior to compiling. Then, in his configure, he sets certain flags, specifically the "arch x86_64" one, to get it to recognize the new setup.