Lot 49: Greg Beaver's blog

A quick note about an obscure problem peculiar to PHP files that make use of PHP 5's new __HALT_COMPILER(); token.  Prior to PHP 5.2.2, if you included two files that contained the __HALT_COMPILER(); token, you would get a notice that __COMPILER_HALT_OFFSET__ was already defined.

This posed a rather large problem for the phar file format, which makes use of __HALT_COMPILER();.  Essentially, this eliminated any possibility of using phar as a library format.

However, never fear, your trusty Greg is here!

With this patch to PHP 5 and this patch to PHP 6, the problem is eliminated.  This patch will also affect applications like PHK that utilize the same principle.  Most of you won't notice the difference until Pyrus, the next generation of the PEAR Installer, is released.

No. At least, we haven't seen any evidence of this assertion.

However, Anne Midgette of the New York Times wrote a very interesting article encompassing her own opinion of the issue. For the article, she interviewed several people with varying perspectives on the issue including the CEO of Chamber Music America, the artistic directors of Chamber Music at Lincoln Center, several concert presenters, a few young performers and composers, and me . One of the most striking parts of the article is where she documents different people's definitions of the term "Chamber Music" itself - it really does seem like nobody has a clue how to successfully define the term, but is this really any different from other genres? Terms like impressionism, pointillism, expressionism all have vast gray areas where renowned experts disagree on what falls within which category. Is Rock music Pop? Is Hip Hop Pop? Is Funk Hip Hop? You could work yourself into a frothy academic frenzy trying to taxonify art properly and still end up with no real definition that everyone can agree upon.

Her main point is that the term "chamber music" is in fact a huge barrier to audiences appreciating chamber music at all. This is an interesting idea, but I find that it is not entirely accurate. The truth is that most people in the United States have no associations whatever with chamber music, negative or positive. She suggests that calling chamber music something else might reinvigorate the field. To me, this seems to be a decent attempt at a new direction, but I doubt that would have any significant effect on either the profession or on audience size at concerts. The content of the concert, the energy level of the group, the focus of the concert (is it a shut-up-and-sit-down event or can you eat dinner while listening to late Beethoven?) are far more significant than what you call it.

All of these nit-picking concerns aside, I am very happy to see an article challenging some of the odd conventions that exist in the world of classical chamber music, and am honored that we were included in the examples of people looking for other ways of doing what we do. It's very exciting to be able to play anything we would play in a concert hall in a club - dumbing down isn't even a consideration when we're putting together our set lists (set list - you might call them "halves" of a traditional concert, and you'd have the same basic idea. Each set is one half of what we end up playing in the club, as we usually play 2 sets).

As an example of one of the tiny things that we can do which is not possible in a concert hall is when we play in clubs, there are no rules about what we can wear on stage. It's quite literally a dream come true for me, as I have always found that suits and tuxedos are designed explicitly to prevent blood from reaching the brain and to prevent audience members from feeling comfortable. We've done our best within the conventions of the concert hall to relax this feeling, but in the concert hall there is no easy way to duplicate the freedom of just being yourself you have when playing in a club.

In short, the thing is useless for anything written using PEAR.  Fun!

Shortly after my last blog post, I got a very helpful email from Rob Richards, who offered to help me with my trials and tribulations. He took a quick look at the schema for package.xml, and a sample package.xml and was able to find two small tweaks to make parsing actually work (gasp). This changes everything. I am abandoning the creation of a relax NG schema in favor of the battle-tested xsd. The error messages for xsd validation are far clearer than the rng ones. For instance with this script:

and the <date> tag moved to the wrong location, I get this error:

Line 565: Element '{http://pear.php.net/dtd/package-2.0}date': This element is not expected. Expected is ( {http://pear.php.net/dtd/package-2.0}stability ).

Fantastic! The error actually tells you what the problem is and gives a useful clue on how to fix it - this is *exactly* what I need to strip out the thousands of lines of unnecessary schema validation code in Pyrus (hallelujah).

I still haven't worked out the problems I was having with rng, perhaps another update on this later.

Update: I've found a solution that will work for Pyrus.  See my next blog post.

While working on Pyrus, the next generation installer for PEAR, I've been attempting to figure out how to leverage PHP's excellent new libxml-based XML validation to speed up package.xml validation in PEAR. To my great surprise and annoyance, I am starting to believe that this is the wrong thing to do.

Originally, I designed a W3C Schema for package.xml 2.0 using XMLSpy, but found that libxml is unable to handle the schema whatsoever. Instead, with the release of PEAR 1.4.0 I designed a schema validator based on the array functions of PHP and the unserialized array generated by XML_Serializer's XML_Unserializer class. Because this is not an elegant validator of W3C Schema or Relax NG, I called it "stupidSchemaValidate()". This is used to validate the basic structure of the XML level-by-level, and so requires many function calls.

I never considered using DTD because it can't handle namespaces.

Now that I am working on the PHP 5+ implementation of Pyrus, the first thing I thought I might do is create a Relax NG schema that the PHP libxml can handle. After an entire day of fighting with the thing, I've managed to discover more than 10 simple and valid Relax NG schema that simply don't work with the version of libxml distributed with PHP 5.2.3. In addition, with helpful error messages like "Expecting name, got nothing here," even with the use of libxml_use_internal_errors() I find the error reporting to be excruciatingly useless.

With my hacked-together stupidSchemaValidate(), I get wonderfully clear error messages like "unexpected <channel>, expecting one of <version>, <date> on line 23" which make it not just easy but simple to debug broken package.xml formatting.

Is there anyone out there who has had any luck getting a supposedly smart external validation tool to print remotely helpful error messages on validating a complex .xml with PHP?

It's been a while since my last blog post, I've found myself with more limited free time than usual and have thus had to focus on the really important things.  I was recently elected president of PEAR (I ran unopposed, so it's a durn good thing I was elected), and this has resulted in a flurry of activity.  A lot of energy is going into revamping the PEAR website, http://pear.php.net.  At this stage, most of the changes are not visible to the naked eye, as we are writing unit tests and refactoring gradually.  However, one change will be highly visible.

I'm excited to announce the first two mirrors of pear.php.net are now actively mirroring the installer REST files and actual .tgz files of package releases.  They are http://us.pear.php.net (provided by Joshua Eichorn and bluga.net) and http://de.pear.php.net (provided by Christian Weiske).  The option exists at a future date of mirroring the entire website, but this will not be possible without further changes to the infrastructure.

To try out one of the new mirrors, simply run:

pear config-set preferred_mirror us.pear.php.net

or

pear config-set preferred_mirror de.pear.php.net

Then, continue using the installer normally.  Users in Europe may notice a considerable performance increase by using de.pear.php.net.  Ain't progress great?

It's been a while since my last blog post, I've found myself with more limited free time than usual and have thus had to focus on the really important things. I was recently elected president of PEAR (I ran unopposed, so it's a durn good thing I was elected), and this has resulted in a flurry of activity. A lot of energy is going into revamping the PEAR website, http://pear.php.net. At this stage, most of the changes are not visible to the naked eye, as we are writing unit tests and refactoring gradually. However, one change will be highly visible.

I'm excited to announce the first two mirrors of pear.php.net are now actively mirroring the installer REST files and actual .tgz files of package releases. They are http://us.pear.php.net (provided by Joshua Eichorn and bluga.net) and http://de.pear.php.net (provided by Christian Weiske). The option exists at a future date of mirroring the entire website, but this will not be possible without further changes to the infrastructure.

To try out one of the new mirrors, simply run:

pear config-set preferred_mirror us.pear.php.net

or

pear config-set preferred_mirror de.pear.php.net

Then, continue using the installer normally. Users in Europe may notice a considerable performance increase by using de.pear.php.net. Ain't progress great?