Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46076
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 209.85.211.201 cause and error)
Message-ID: <4B034CE9.7020207@chiaraquartet.net>
Date: Tue, 17 Nov 2009 19:24:57 -0600
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Kalle Sommer Nielsen <kalle@php.net>
CC: PHP 'Internals' Wonderland <internals@lists.php.net>
References: <2dedb8a0911161713m5d8c3d3dma5013968d11f586f@mail.gmail.com>
In-Reply-To: <2dedb8a0911161713m5d8c3d3dma5013968d11f586f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: PHP6's future
From: greg@chiaraquartet.net (Greg Beaver)

Kalle Sommer Nielsen wrote:

> But what is every ones input on the matter of attempting to boost
> PHP6's development? I'm willing to give my part in whatever I can to
> help getting up on the feet to get this ball rolling.

Hi,

As someone who has successfully ported a rather complex extension (phar)
to PHP 6 compatibility, and in the process found and fixed a serious bug
in the core stuff for converting from and to unicode, I can say with
some authority that this is a huge job.

Fortunately, even though it's huge I think the task is far simpler than
deciding on a roadmap.  All of the core functionality already exists
(check out the README.UNICODE* files to see how it works).  We also have
.phpt tests for just about everything thanks to testfest.

What needs to happen is for developers to focus on finding problems
highlighted by failing .phpt tests.  The most complex extension that
needs some loving is the SPL extension.  I would hazard a guess that if
these .phpt tests are fixed, a large number of roadblocks will disappear.

So, if you want to fix PHP 6, setup gdb (or if you'd a GUI dweeb like
me, ddd), and start fixing spl .phpt tests, and then move on to the
other extensions.

Once these tests pass, it will then be possible to talk more roadmappy.

I should also point out that the memory leaks at the end of building PHP
6 when phar.phar is created were introduced by my bugfix because the fix
involved adding an emalloc()ed pointer that must be freed.  I think some
of the oldest code relies upon the old behavior and doesn't free it, so
if these can be found, it will get rid of the leak.  The bug I fixed
manifested itself with a random crash when running the .phpt tests, and
was seriously hard to isolate, so please don't revert my fix unless you
know what you're doing :).

Greg