Skip to content

php

  • in php
  • 2 min read

PHP 5 Extension Dependencies - we need your help

update (in response to a recent comment): this patch is already in the 5.1 tree; please test that instead; thanks!

[patch updated again: if you have a BSD-ish system that complained about "making too many open files", please try it again]

[patch updated: please try it again. Note that if you only have "mawk" you should install GNU awk instead, as mawk is broken]

I've created this patch to force extensions with dependencies on other extensions to be initialized in the correct order when they are compiled statically into the core of PHP.

It's known to work on Linux (and Tru64--thanks Magnus), but we'd really like to know if it works on other systems too--we don't have access to them, and we really want to get this into PHP 5.0 (due in July!).

So, please test it if you have SunOS, Solaris, BSD, HP UX, AIX, IRIX or any other "weird" unix systems.

Instructions:

Checkout PHP 5 (or download a snapshot from snaps.php.net)

Apply the patch: 

   cd php5
   curl http://www.php.net/~wez/configure-deps.diff | patch -p0
   ./configure

Now look in main/internal_functions.c and/or main/internal_functions_cli.c

You should see something like this in the file. Each line corresponds to the extensions you enabled through configure; your list may be longer or shorter depending on how much stuff you compile into PHP. 

   zend_module_entry *php_builtin_extensions[] = {
    phpext_libxml_ptr,
    phpext_xml_ptr,
    phpext_tokenizer_ptr,
    phpext_sysvshm_ptr,
    phpext_sysvsem_ptr,
    phpext_sysvmsg_ptr,
    phpext_standard_ptr,
    phpext_sqlite_ptr,
    phpext_simplexml_ptr,
    phpext_spl_ptr,
    phpext_session_ptr,
    phpext_posix_ptr,
    phpext_pcre_ptr,
    phpext_pcntl_ptr,
    phpext_gd_ptr,
    phpext_ftp_ptr,
    phpext_exif_ptr,
    phpext_ctype_ptr,
    phpext_calendar_ptr,
    phpext_bz2_ptr,
    phpext_bcmath_ptr,
    phpext_zlib_ptr,
};

If you see libxml before xml, it's worked. If you see repeated entries, it broke.

Please try building it now too.

If it all works, please either comment here, or send an email to internals@lists.php.net indicating which platform you used.

If it breaks while compiling main/internal_functions.c and/or main/internal_functions_cli.c, please let me know by email to wez@php.net.

Prefix the subject with [DEPS-PATCH], and include the name of your platform and the internal_functions.c file.

Thanks for helping to make PHP 5 better :-)

PDO Slides from php|works

You can find them here.

Update: I realized this morning that I didn't mention meta-data (as in column types and sizes) as one of the things on the horizon in the slides (nor in the talk; doh!).

PHP | Works

toronto I'll be in Toronto for php|works in a few days time. I'll also be around for a couple of days after the conference (flight was cheaper that way).

See you there?

  • in php
  • 1 min read

MySQL ComCon Europe 2004

via Zak:

The Shaken (but not stirred) Announcement

Recipe for MySQL ComCon Europe 2004:

  • Take equal parts kick-ass MySQL community event and MySQL mission-critical business event.
  • Add key MySQL community members and developers.
  • Drop in three days in November (8th to 10th).
  • Shake well.
  • Serve ice cold at http://mysqlcomconeurope.com/.

If you're interested in attending, by all means beg/bribe, borrow or steal to get there; a lot of effort has gone into organizing the event, particularly into getting the developers to be at the same place at the same time, so make the most of it!

  • in php
  • 3 min read

GOTO isn't evil

In reference to Sara's patch to implement GOTO in PHP:

It saddens me that people are so easily brainwashed by their teachers/peers. Sure, from a high level perspective you don't need a GOTO statement, and the argument that it, when misued, can lead to unreadable code is a good one.

However, I feel that the inverse argument can also be true: complex code with lots of nested if statements and control loops can be also be hard to follow when you need to "get out of jail" fast. Without goto you often need to resort to tricks (in C) such as "do { ... break; ... while (0)", or if you have nested switch's inside loops, create a flag variable and take several steps out of each nesting level. There is no way in hell you can convince anyone of sound mind that those tricks make the control flow easier to understand than a GOTO.

No doubt the anti-goto brigade will campaign that the code could be split up into different functions etc. etc. etc., but it is quite often the case that real programmers need to have this stuff in one function; just take a look at kernel code written in C, for example.

Arguments against GOTO on the following grounds are, IMO, just a bit short-sighted:

  • I think GOTO is bad because some guy wrote a paper on it
  • I was taught not to use it. (But don't know why; it's supposed to be bad, or something).
  • I was taught not to use it because you can use something else.
  • You can use exceptions instead; who cares about performance

Regardless of who wrote the paper, or what you were taught, or your disregard for performance (which does have a big impact in the real world; Exceptions are expensive), GOTO is sometimes needed to get the most out of your code. I'll even go so far as to say that most of the people making these anti-goto comments have no practical experience either of using goto, or with dealing with someone elses misuse of goto; if you don't have experience, please shut the hell up :-)

GOTO is one of those tools that you don't always need, and one where it is hard to define precisely when you should use it (<insert anecdote about professor who determined only one extremely rare case you can't handle without goto>). It boils down to what is appropriate for the task (and language) at hand.

Use your brain and evaluate the project--don't just blindly follow what others have said in the past; make up your own mind. If you truly believe that a goto makes a certain section of code more readable, go ahead and use it. If you deduce from benchmarks that exceptions, nested loops with flag variables or whatever are too slow or otherwise too expensive, you have have a perfectly valid reason to use a goto instead.

I'll sum up with a "GOTO doesn't kill code, bad programmers do". Just because misuse of GOTO can be harmful, it doesn't mean that it shouldn't be part of your toolbox, and for that reason I would welcome a GOTO statement in PHP.

More on PDO

Just published today on the Oracle Technology Network is my article on PDO, giving an overview of what it is, installation, sample code, portability and so on.

Although it has a focus on Oracle, pretty much everything covered there should be portable to the other available pdo drivers with minimal changes (essentially just the parameters to your connection), if you are writing portable SQL.

Please do read it, even if you're only mildly curious, as the stipend I earned from writing the article effectively paid for some of my time working on PDO. As it was actually written a few weeks back (OTN has a long publishing process), the "Future of" section is missing details of the iterator (eg: foreach) support that Marcus keeps nagging me to merge in.

  • in php
  • 1 min read

ActivePHP

People seem to have only just noticed this thing, but it's been around for ages (2 years!). Yeah, it's probably broken in PHP 5 in a bunch of places. It's experimental, YMMV. Yes, I care if it doesn't work for you; maybe not enough to use up my spare time (not that I actually have any) debugging windows problems, but everyone understands that you get what you pay for, right?

Wrong

Our brief conversation took place the day before his somewhat "unfriendly" posts. I received 2 emails, not 6.

Andrew:

OpenSource is about contributing, so why not contribute something useful to the rest of the world instead of angry vibes and misrepresenting the people that have already donated so much of their time?

If you want to help yourself, take a look at the CVS and compare PHP 4 with PHP 5. It sounds like there is a buglet in the registry entries; it did work under PHP 4 with WSH, so why not start by comparing those parts?

PS: threaded PHP is a bad idea waiting to crash. That's one of the reasons why we strongly recommend that you don't use threaded SAPI under windows (and even under unix if you can avoid it).

Back from LinuxTag

After a surprisingly long day of travel (each leg of the journey isn't that long, but the whole is greater than the sum of its parts), I'm back home in England.

I did't take any photos this year, but if you're curious, Tobias has rounded up a whole bunch.

I'd like to thank ThinkPHP for sponsoring my journey and stay at LinuxTag again this year; the critical mass of PHP brains at a conference usually results in something new for PHP, and it is good that ThinkPHP recognize and help this to happen.

So what's coming out of LinuxTag? We had a database meeting again this year; last year it spawned PDO, and this year we (most of the major PHP database extension maintainers) sat down and refined some aspects of it. Other cool stuff is hinted at here, and will be very useful if used wisely.

Come to the LAMP Area @LinuxTag

I will be giving a talk on PECL in the LAMP Area at LinuxTag this month. The talk will focus on why PECL is good for both users and developers. If you're interested in that, please come along.

I will be there all week, so there should be plenty of time to discuss cool things in PHP and/or hassle me to finish up one of the numerous things that I've started since the last conference run.

I'm looking forward to it: LinuxTag is easily the best conference in Europe (in my experience)--plenty of things to look at, in a good location, and with excellent company.

Hopefully there will be an alternative to Jolt Cola this year...