staying neutral

Finally.

After years on working on RE2C to make it stable and ready to replace flex-based scanners, work on replacing PHP's flex-based scanner with a RE2C-based one has begun. Actually the work was started by Nuno Lopes and Scott MacVicar on 14th of February 2008, after I happily informed them that I considered RE2C ready for this task. I joined the work a day later, contributed a few ideas and helped with minor RE2C improvements. Today on the 15th of February we can already run make test and get over 98% PASS.

This encouraged me to spend a bit more time on RE2C and release 0.13.2, which you can download here (sorry but it is on sourceforge).

Thanks to Scott, we also have a subversion and Trac setup here, where you can follow our development. If you want to experiment yourself, or even help in our efforts, then you can checkout from svn://whisky.macvicar.net/php-re2c.

Blogged with Flock

Labels: PHP, RE2C

So I've had enough of different PHP versions compiled in different modes (ZTS or DEGBUG) and having to change the php.ini file every now and then on my dev machines. So I added conditional INI support:


I used square brackets for the conditionals, as it seemed the way that comes with the least potential for INI handling. This is because right now we ignore section names anyway.

The patch can be downloaded here and allows for the following:

• String comparison using operators === and !==.
• All other operators convert left and right operands to integers first, just as INI handling would do for value evaluation.
• Support for operators <, <=, >, >=, ==, !=, && and ||.
• Braces can be used to force an evaluation order.
  
• No support for unary operator ! or ternary operator ?:.
• No support for functions.
• No direct boolean evaluation, that is operators are required.
• Conditions can be nested.
  

If you are interested in this stuff, you can either comment on this blog entry or follow the discussion on internals@php.net here.

Blogged with Flock

Labels: PHP

So after the initial uproar on last week's attempts to put parts of PHP development under the terms of a CLA (read proposal here), a bunch of us actually spent some time in finding solutions for one way or the other. I don't want to bother you with more details on the why.

But, one thing for certain, we want PDO.

As the reasoning, this was discussed enough, so I'll jump directly to my ideas for a solution.

• Develop a PECL CLA that can optionally be used for PECL projects.
• If necessary, adapt the PHP License, so that it works nicely together with the CLA.
  
• The projects that want a CLA can choose between the PHP License or LGPL.
• Change the PECL web site so that projects can opt-in to using the CLA.
• Arrange it so that projects cannot drop the CLA flag.
  
• Add a user/CLA/project table to the PHP user database, and use this in CVS ACLs.
  
• Create a new CVS module php-default.
• Move all extensions that can be disabled and are not required for others to PECL.
• Link everything under php-src plus a default selection of extensions to php-default.
• Let us once and for all ban CLAs from php-src aka PHP core.
  
• Start developing PDO as part of CVS module php-src.

Sorry for not writing this earlier. So how does this idea sound? Check out answers to the mail here.

The Borg Queen to Kathryn Janeway: 'Do as all pragmatists do, compromise'. And it is no secret that I am a pragmatist.

Blogged with Flock

Labels: PHP