Want to try out PHP5.next (PHP5.4?) on Ubuntu?
After the death of PHP6.0 a while ago, development of PHP.next (PHP5.4 probably?) has been going on.
There are a lot of cool features there try out - like traits, scalar type hint, and sh**loads of smaller features.

There is still no public "development preview" or alpha release, but that doesn't mean we can't play around with it, report bugs, ensuring our apps still properly work with it etc etc etc.
It is however a bit annoying needing to "go old-school" and fetch a snapshot and build it yourself though.

When I was playing with launchpad the other day I figured.. why not provide a daily build of PHP trunk/ (PHP.next, PHP5.4 or whatever you want to call it)?

Launchpad isn't all to happy with git, and doesn't support mirroring git branches, so a fork of the php5-vanilla-ubuntu repo to php5-next-vanilla-ubuntu was needed as some of the patches there don't apply to trunk/. But that was about it.

So, want to try out PHP5.4 daily builds? Checkout the PHP5.4-daily PPA on launchpad!

Play around with the new features, provide feedback to the PHP development mailinglist, and make sure your application if forward compatible with it today.

It’s easy for us to look around at the technology we work with every day and think that we can solve all of the worlds problems with a few lines of elegant code. We think that just because we have a mastery of our language of choice, that we can conquer any challenge we might face. The only problem is that we’re forgetting one thing. No matter how much code you write or how much time you spend pouring over that shiny new architecture you’ve dreamed up, there’s one thing that can never be replaced – the human element.

Most of the developers I know have started off with a language the same way – they heard about it from a friend. They casually heard the name “PHP” dropped in a conversation and either (depending on how outgoing they are) jumped in to the conversation or made a dash home to look up what everyone else seemed to be talking about. Without this word of mouth, I dare say quite a bit of the technology that we have today wouldn’t be around. Think about it – how many times have you looked at a new language or bit of tech just because someone else you trust said it was cool. Sure, it might sound a little like siding with the popular kid, but what happens if that kid’s the one who’s right? That language may be the next big thing – if not for the online community as a whole, then just for you and your development.

Think back to when you first started programming PHP (that may be yesterday, that may be ten years ago) and think back to all of the influences you had along the way. Chances are you didn’t make it to where you are today without a little help. You found blog posts of others that solved the same problems, you hopped on IRC and talked with like-minded folks trying to overcome the same hurdles and you shared you own experiences for the future generations of web developers to learn from. You’ve come full circle, sharing what you know back with those who need it the most. You’re a contributing member of the community.

So, why am I writing this if it’s all so obvious to even the most casual observer? I wanted to reinforce the fact that, even if you’re new to the community or you’ve been writing PHP so long you dream about namespaces and PHP6, you can always be more involved. Technology is great, but really – people are better. I can’t recommend enough the effort that the PHP Community Conference is doing to bring this human aspect back into the conference scene. They’ve taken the traditional conference mentality, turned it on its side and put an extra helping of emphasis on the thoughts behind the technology and less on the syntax of the day-to-day. This approach provides an interesting perspective, different from the usual track-based methods (similar to the Brooklyn Beta event).

If you haven’t looked at the conference, time’s getting short – it’s happening about a month from now, April 21st and 22nd, in Nashville. I’ll be there as a speaker talking about my first PHP love – PHPDeveloper.org and doing what I can to give back as much to the community as possible. Because really, without each other to help us through, none of us would be where we are today.

UPDATE: I want to take a second to apologize for any poor choice of wording I’ve used in this post. My intent wasn’t to make conferences like php|tek or ZendCon seem less in comparison to the PHP Community Conference. It was more of a commentary on the different conference styles – the “why” PHPComCon offers rather than the “how” sessions that several of the others provide. The ironic thing is that I’m also in the process of planning my own conference and it follows the track-based ideas. It’s a difficult process and I have a growing respect for people like Keith Casey, Marco Tabini, Cal Evans and the scores of other folks behind the scenes of these excellent events. They work their hardest to keep people from “feeling like a number” during their events, and – especially tek – keeping the community as a large focus. My hats are off to them for planning not only quality content during the day but fun, engaging activities during the evenings that bring community members together from all over the world to laugh, enjoy a few beers and shoot the breeze about all things PHP.

PECL OCI8 1.4.4 has just been released. It fixes a potential memory corruption using oci_set_* functions seen on 64 bit machines. This release can be used to update OCI8 on earlier PHP versions.

During testing, command line PHP worked fine but in browser I immediately got the infamous error:

    Warning: oci_connect() [function.oci-connect]: OCIEnvNlsCreate()
    failed. There is something wrong with your system - please check
    that LD_LIBRARY_PATH includes the directory with Oracle Instant
    Client libraries in /home/cjones/public_html/ed.php on line 2

I thought I'd seen all causes of this error before. It means the web server doesn't have the Oracle environment set correctly. Commonly it happens on Windows machines with multiple versions of Oracle installed.

Since I had a reproducible test, I took the time to enhance OCI8 1.4.4 to display the underlying error message. Several people had been asking for this:

    Warning: oci_connect() [function.oci-connect]: OCIEnvNlsCreate()
    failed. There is something wrong with your system - please check
    that LD_LIBRARY_PATH includes the directory with Oracle Instant
    Client libraries in /home/cjones/public_html/ed.php on line 2

    Warning: oci_connect() [function.oci-connect]: Error while trying
    to retrieve text for error ORA-01804 in
    /home/cjones/public_html/ed.php on line 2 exiting

My web server environment was so screwed that Oracle couldn't even locate the message files to print ORA-01804: failure to initialize timezone information, which was the failing part of initialization. Sadly the new message wasn't much help in resolving my situation. I eventually tracked down the cause to httpd.conf having:

LoadModule php5_module        modules/libphp5.so
LoadModule php6_module        modules/libphp6.so

It's not valid to load multiple versions of PHP like this but Apache was starting without logging an error. My left-over PHP 6 library statically linked OCI8 and an ORACLE_HOME. My PHP 5 loaded OCI8 via extension=oci8.so and this was built with an Instant Client. The end result was an Oracle library clash.

The solution was to remove the LoadModule line for PHP6. You are unlikely to hit this exact problem, but it is a lesson in how the environment needs to be valid. Oracle messages can't always pinpoint set up issues. Care and methodical elimination of causes is needed to resolve similar problems.

Here is a list of various articles about PHP-GTK2, recently updated:

• 2010-05-10 : HOWTO: Compile php-gtk2 for Lucid Lynx
• 2009-11-02 : Deploying a PHP-GTK application with NSIS, by Matthew Casperson
• 2009-07-07 : Beginning PHP-GTK: Signals, on Codecall.net
• 2009-06-29 : Beginning PHP-GTK: Creating a Simple Interface, on Codecall.net
• 2009-04-25 : Building PHP-GTK with Cairo Support on Ubuntu Jaunty, on IShouldBeCoding.com
• 2009-03-28 : Distributing PHP-GTK applications on Windows (not a reference to Gnope or Scott's chapter on the subject)
• 2009-01-25 : building PHP-GTK 2 with PHP 6. A set of patches and an explanation
• 2008-03-05 : a fresh intro to PHP-GTK by Bob Majdak
• http://www.developertutorials.com/tutorials/php/building-desktop-applica...

read more

Being the verbose kind, I guess I will put in a summary at the top leaving the original post below for everyone to read all the little details. Essentially the summary is that I (and many other core developers) agree that HEAD/trunk in its current form was stalling future development on PHP. Jani indirectly jump started the discussion of moving this stumbling block out of the way by essentially doing two commits that violate the most fundamental rules of PHP development (and common sense courtesy) we have. I am worried that this will lead to confusion in the user base and other seem to think that the "ends justify the means". I also think that we need clearer processes to make it easier for new developers to have a clear path to follow in order to get things done in PHP.

Full story:
So this all requires a bit of background. I still remember my first contact with a PHP core developer. I do not quite remember the year, but it was quite some time ago. Anyway Jani was great, we filed a bug report on the imap extension. He fixed the bug in no time. IIRC we also ended up sharing a room at the second IPC in Frankfurt I attended. I think only a few years later I realized that Jani is the same guy a lot of people were complaining as being rude. But I guess few of these people realize how much time Jani has spend on verifying bug reports and what a tedious job this is, especially since most bug reports are quite low on the actual relevant details and come with a "fix my code for me, now!" attitude. In other words, I get along fine with Jani and I have great respect for his contributions to PHP.

Next piece of background. I am also one in the long list of people that has made a fool of himself by predicting a release of PHP6 in about 18 to 24 months (quite a few people have given this prediction over the past 3-4 years I guess). I have also been one of the people that has tried to motivated people at various times to finish those last 2% that seem to be missing to complete PHP6 in terms of functionality. As such I have opposed a PHP 5.4 because I felt its time to focus on finish up PHP 6 which we have promised people for so long. After releasing 5.3.0 I was hoping things would happen. But last weekend I came to the realization that we have waited long enough. That even if PHP 6 would be unicode bliss (at least in terms of features, probably not in terms of performance), the fact of the matter is that in all of the many years nobody put in the time to finish it. This imho is an indirect proof that the approach taken apparently does not hold enough merit to the world in general. Furthermore looking at internals since last summer it has been more dead than ever: PHP 6 aka HEAD aka trunk had become such a motivation killer that nothing was happening.

At the same time I knew that suggesting to move trunk to a branch and copying 5_3 to trunk would cause a lot of confusion. Not only among those reading internals, but also that this would quickly make it to the news sites of the world. Call it politics, marketing or just an unwillingness to cause thousands (millions?) of PHP developers distress and uncertainty, but I figured it would be better to propose this with a semi solid plan and giving a number of PHP core developers the heads up that I will bring this to the list, so that they also could prepare themselves. So I started talking to people offlist, either in person, via phone, via IRC/skype or via email with the full intention of going to the list no later than the end of this month, ideally sooner rather than later. I should also note, I do not code C, I also do not consider myself a unicode expert. So if I wanted to present a plan, I obviously needed to talk to people to get my facts straight.

Anyways, this week Jani decided to commit a patch. I guess I didn't mention one more piece of background. Jani had asked to get this patch into PHP 5.3 during the pre alpha stage, but at the time Johannes and I (I was co-RM back then) felt that the patch hadn't been tested enough in HEAD and that while we knew the patch fixes several bugs, we felt the risk of introducing new bugs was too high, especially since Michael who wrote the original patch for HEAD was not always around to fix things. Johannes had tried to get the patch into 5.3 six months earlier, but at the time nobody had time to do the work. So we decided to stick with the known bugs, instead of fixing them and risking new bugs in a very core component of PHP close to going alpha. So basically Jani committed a huge patch into a stable branch, without talking to anyone about this, despite knewing full well that the RM had specifically vetoed this patch in principle. Furthermore the patch from my understanding even breaks the ABI which makes the patch even more a no go.

No

Truncated by Planet PHP, read more at the original (another 6351 bytes)

Voici quelques articles sélectionnés à propos de PHP-GTK2&nbsp:

• 2009-11-02 : Déployer une application PHP-GTK avec NSIS, par Matthew Casperson
• 2009-01-25 : comment compiler PHP-GTK 2 pour PHP 6. Un jeu de correctifs et une explication
• 2008-03-05 : une introduction à PHP-GTK 2 par Bob Majdak
• http://www.developertutorials.com/tutorials/php/building-desktop-applications-in-php-8-02-01/page4.html

en lire plus

So, every once in a while I find myself in need of trying out newer, maybe, not-yet-released features in PHP. For example, recently, I wanted to test RoundCube PHP6 — this is how I did it.

On a side note, the same setup would also work for testing code with previous versions of PHP.

Toolbox

I used nginx and the PHP source with a little bit of ./configure and make — for kicks!

My O.S. of choice is FreeBSD and therefor the installation steps covered are tailored to it. With a small amount of Linux/Unix-fu, anyone should make it work on another distribution regardless.

Install nginx

First off, install nginx. On FreeBSD, this should be all:

• cd /usr/ports/www/nginx-devel && make install distclean

On other systems, this maybe a:

• apt-get install nginx
• emerg nginx
• rpm -shoot-myself nginx

The next step includes the infamous spawn-fcgi which many people use to control the php-cgi processes. A lot of tutorials on the net suggest to install lighttpd because it's a part of it, but on FreeBSD, you may skip that and do the following instead:

• cd /usr/ports/www/spawn-cgi && make install distclean

Pretty cool, huh?

So once this is done, the usual tasks need to be completed — in no particular order:

• edit the nginx config and enable fastcgi in nginx (/usr/local/etc/nginx/nginx.conf)
• enable nginx itself in /etc/rc.conf (nginx_enable="YES")
• get another nifty start script (see Shell Script) to wrap spawn-cgi

... and done!

... more after the jump.

After my colleague Cal reviewed DPC's tutorial day, it's now my turn to look back at the first real conference day of 2009's Dutch PHP Conference.

The day started with a nice movie made by Almer and Norman after which Cal officially opened the Dutch PHP Conference and introduced Andrei Zmievski to do the opening keynote. Andrei gave an outline of developments in PHP including the changes we are going to see in future versions. Closures, namespaces, better garbage collection and a few more things are coming to PHP5.3, but I think this isn't new to most people. I haven't really read a lot on PHP6 yet other than Unicode, so the addition of traits, C# style getters and setters and scalar/return value type hinting were new to me. I think this was a nice talk to be the opening keynote, because other than just being infomrative the talk also had the right amount of humor with some examples of frustrated people reporting "bugs" and a setting for y2k compliance. I wasn't active in PHP 10 years ago, but it made me laugh when I heard that the y2k_compliance setting basically did nothing other than stop people asking about it.


Continue reading "DPC 2009 Day 1"

After my colleague Cal reviewed DPC's tutorial day, it's now my turn to look back at the first real conference day of 2009's Dutch PHP Conference.

The day started with a nice movie made by Almer and Norman after which Cal officially opened the Dutch PHP Conference and introduced Andrei Zmievski to do the opening keynote. Andrei gave an outline of developments in PHP including the changes we are going to see in future versions. Closures, namespaces, better garbage collection and a few more things are coming to PHP5.3, but I think this isn't new to most people. I haven't really read a lot on PHP6 yet other than Unicode, so the addition of traits, C# style getters and setters and scalar/return value type hinting were new to me. I think this was a nice talk to be the opening keynote, because other than just being infomrative the talk also had the right amount of humor with some examples of frustrated people reporting "bugs" and a setting for y2k compliance. I wasn't active in PHP 10 years ago, but it made me laugh when I heard that the y2k_compliance setting basically did nothing other than stop people asking about it.


Continue reading "DPC 2009 Day 1"

I am such a torment. Cancelled negotiations with a publisher over disagreements on a book format? Check. Said no to taking down a free book startup and enter a publishing contract? Check. Lambasted multiple publishers for releasing PHP 6 books which do not teach anything PHP 6 specific? Check. Next month I expose which publishing companies are secretly building weapons of mass destruction in their basements. Reverse that, I can't afford a libel suit...

In "The Art Of Deception Or Publishing PHP6 Books" I aired my unflattering opinions about publishers who have been selling "PHP 6" books. PHP 6, last I checked, was a bit like Leprechauns (Hey, I'm Irish! The use is legal!). You love them, you have lots of ideas about what to expect from them - but has anyone every really seen one (other than my great uncle)? PHP 6 exists in CVS - it's never had a release other than the usual CVS snapshots. It's certainly not complete and stable, and its future feature list remains a bit flexible. You could see PHP 5.4 in 2011 before PHP 6 is finished...guessing here. As its developers would say - it'll be ready when it's ready. One day. Maybe.

In response to the blog post, Wrox Press picked up on the problem on Twitter via Davey Shafik (@dshafik). Everyone knows Davey. If you don't, you must have been living under a rock, or a ruby, for a really long time. I have to say, Wrox responded in a wholly unpredicted way I have to admire. It's not everyday you find yourself hiding in a cave in Antrim (it's nice...a little damp though) after seeing something you wrote persuade a publisher to pull back a book destined for the printers, and work on fixing it so it deserves its title.

Here's the full text of the comment posted to "The Art Of Deception..." earlier today by Jim Minatel (Associate Publisher - Wrox). Jim is mostly the person sitting behind @wrox over on Twitter where he's been quite proactive in getting to the bottom of my PHP 6 Book complaints.

Pádraic:

Thanks for taking the time to discuss this with me on Twitter last night. I’m the Associate Publisher for Wrox, I’m the person usually behind @wrox on twitter.

After meeting with the editor who ran the PHP list for us, you’re right. The titles of these PHP6 books, some of the references to PHP6 in the books, what isn’t covered in the books, all prove we made a mistake, something went wrong. But how, why?

Elizabeth (and thanks for her measured response) is correct in part of her assessment that books take a long time to write and publish. I’m sure that when the editor and authors started these books in Spring 2008, they’re thinking was that 6.0 would indeed be a stable release by early 2009 (if not sooner) and they were aiming for that. But clearly along the way we dropped the ball on checking references to things like the non-existent “6.0.0 stable.”

In the Beginning PHP6, MySQL, Apache book, I can actually understand the rationale not to cover Unicode there. Given that Unicode is primarily valuable to someone internationalizing a site or localizing it for multiple languages – topics that I wouldn’t consider “Beginning” level – I can see why it wasn’t covered. (Before becoming associate publisher, I was actually our ASP.NET editor for most of the last 5 years and we don’t for example cover internationalization/localization in our Beginning ASP.NET 3.5.) So we want to have a book that Beginning level customers understand will work with PHP6 if that’s the version they’re using, but we didn’t communicate right what that meant in this context where there weren’t major new v6 features at the level we thought a beginner would need.

The professional book stumps me more. It’s hard for me to understand how that book doesn’t have a chapter on Unicode. It looks like an oversight by everyone involved in the book.

So where do we go from here and get better than this to eventually prove we’re worthy of better than when @bicatu says “That reminds me why I've never bought a Wrox book?”

First, I’ve asked the team involved with Beginning PHP6 scheduled to ship to the printer this week to pull that book back, to read your post and the subsequent twitter discussion and to make sure we aren’t making the same mistake a third time. I want the author and editors to provide a level of confidence that the PHP6 features that should be covered are, that the discussion of the current state of PHP6 is accurate, and the that the title, subtitle, and marketing copy on the book and online accurately reflects what is and isn’t covered.

Second, publishing the ri

Truncated by Planet PHP, read more at the original (another 1839 bytes)