[PHP-DEV] PHP 5.4 alpha

Hi,

we're a bit further along now; and with the typehinting resolved
(http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858) I want
to start started with PHP 5.4 with the first alpha on Wednesday,
November 24th. There are a few things that need sorting
out and/or clarification:

- Annotations
- Lemon rewrite
- APC in trunk

I don't think we can sort out the latter two before the alpha/branching.
For Lemon because the rewrite apparently makes things slower; and for
APC because it's still quite a lot of work to make it even work with
trunk. For each of those three points, I will reply to this mail with a
summary, and some suggestions.

Please reply to this mail only for something else than the above three
mentioned topics.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

The RFC on annotations for PHP http://wiki.php.net/rfc/annotations
suggests to add new syntax to the language to provide meta data for use
in reflection. This sort of meta data is usually provided in the form of
docblocks, which this RFC does *not* state isn't good enough.

The discussion on the mailinglist did not provide a clear consensus for
either for or against. We could put this up for a vote, but I feel that
that is not useful right now, because a few issues needs to be sorted
out first. First, where we actually require annotations (over the
current practise of using docblocks); and secondly whether we really
want to introduce another syntax into the PHP scanners and parsers.

For now I would suggest that this proposal needs to be sorted out before
we can even suggest of putting it in PHP 5.4.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

Work has been done on rewriting the PHP parser to Lemon in a specific
branch: http://svn.php.net/viewvc/php/php-src/branches/LEMON/

Right now, the Lemon parser is not actually faster than the current
bison parser, so I would suggest not to put this in PHP 5.4 until it
performs at least as well as the current parser.

Are there any possibilities for optimisation so far?

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

I understand that the general idea is to bundle APC with a future
version of PHP. Right now, APC doesn't really compile for trunk because
of internal changes. However, for PHP 5.3 it's getting into a pretty
good shape. In order to add APC, what does still need to be done?

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Nov 01 15:33:59, Derick Rethans wrote:
> Hi!
>
> Work has been done on rewriting the PHP parser to Lemon in a specific
> branch: http://svn.php.net/viewvc/php/php-src/branches/LEMON/
>
> Right now, the Lemon parser is not actually faster than the current
> bison parser, so I would suggest not to put this in PHP 5.4 until it
> performs at least as well as the current parser.
>
> Are there any possibilities for optimisation so far?

I'd make the guess that it is slower due to the rule decomposition that
we had to do to match bison's "mid-rules" syntax.

We could surely optimize the decomposition but it would require a lot of
rewrite in zend_compile.c, which is quite tricky to do.

>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
Etienne Kneuss
http://www.colder.ch

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, 1 Nov 2010, Derick Rethans wrote:

> I understand that the general idea is to bundle APC with a future
> version of PHP. Right now, APC doesn't really compile for trunk because
> of internal changes. However, for PHP 5.3 it's getting into a pretty
> good shape. In order to add APC, what does still need to be done?

Actually, Kalle just pointed out that it compiles just fine. In that
case, I think we should put it in trunk and in the 5.4 alpha.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

> (http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858) I want
> to start started with PHP 5.4 with the first alpha on Wednesday,
> November 24th. There are a few things that need sorting

I just wanted to remind we have ZendCon this week, which means some
people who might have something to say about this are either busy, in
travel, or both. Please keep this in mind.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Derick,

I'm all for it.
Although I have karma, I'm not an active PHP core contributor, but I
would like to participate of such discussion, mainly because I have
plenty experience with Annotations from another languages.

I'll spend some time re-reading the entire Annotations thread and come
up with another proposal at the right time.

Regards,

On Mon, Nov 1, 2010 at 8:33 PM, Derick Rethans <[email protected]> wrote:
> Hi!
>
> The RFC on annotations for PHP http://wiki.php.net/rfc/annotations
> suggests to add new syntax to the language to provide meta data for use
> in reflection. This sort of meta data is usually provided in the form of
> docblocks, which this RFC does *not* state isn't good enough.
>
> The discussion on the mailinglist did not provide a clear consensus for
> either for or against. We could put this up for a vote, but I feel that
> that is not useful right now, because a few issues needs to be sorted
> out first. First, where we actually require annotations (over the
> current practise of using docblocks); and secondly whether we really
> want to introduce another syntax into the PHP scanners and parsers.
>
> For now I would suggest that this proposal needs to be sorted out before
> we can even suggest of putting it in PHP 5.4.
>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2010/11/2 Derick Rethans <[email protected]>:
> On Mon, 1 Nov 2010, Derick Rethans wrote:
>
>> I understand that the general idea is to bundle APC with a future
>> version of PHP. Right now, APC doesn't really compile for trunk because
>> of internal changes. However, for PHP 5.3 it's getting into a pretty
>> good shape. In order to add APC, what does still need to be done?
>
> Actually, Kalle just pointed out that it compiles just fine. In that
> case, I think we should put it in trunk and in the 5.4 alpha.

Absolutely! (+1)

> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


--
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, 2010-11-01 at 15:32 -0700, Derick Rethans wrote:
> Hi,
>
> we're a bit further along now; and with the typehinting resolved
> (http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858) I want
> to start started with PHP 5.4 with the first alpha on Wednesday,
> November 24th. There are a few things that need sorting
> out and/or clarification:
>
> - Annotations
> - Lemon rewrite
> - APC in trunk
>
> I don't think we can sort out the latter two before the alpha/branching.
> For Lemon because the rewrite apparently makes things slower; and for
> APC because it's still quite a lot of work to make it even work with
> trunk. For each of those three points, I will reply to this mail with a
> summary, and some suggestions.
>

It strikes me that PHP is a bit bound up by conflicting interests, as
any good language should expect to be as it matures and grows beyond its
original focus.

I wonder if a more structured release cadence would improve the
experience for developers. One of Ubuntu's strengths as a development
platform is that there is a clear date that, should a feature be
specified and agreed upon by, it will be included in the release. The
criteria for each of these freezes are well published, and so plans can
be made based on how close to these criteria any one feature is.

As an example of this, the RFC for annotations has been well discussed,
but no decision about whether or not a syntax element is necessary or a
good idea has been made. Its status as a blocker for 5.4 would only be
considered until a certain point, a "feature definition freeze", and
then after that, it is rejected completely for the release. This does
not mean work stops on it, but rather the effort now has a new timeline.
Likewise if it is defined enough to be included, it may still fall out
if the implementation falls behind.

The alternative, of trying to make everything fit together, seems like
it will just lead to things taking much, much longer.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Derick Rethans wrote:
> Actually, Kalle just pointed out that it compiles just fine. In that
> case, I think we should put it in trunk and in the 5.4 alpha.

As long as it is disabled by default and can easily be replaced by preferred
alternatives ... eaccelerator is still working fine now that it has been
upgraded to handle 5.3 ... although it would be nice to see some more up to date
comparisons. Although I suspect in reality, the combination with database and
other caching activity means that a straight comparison may be a little
meaningless? Change the database and the figures are going to be different
anyway ... so a straight comparison on non-database code would be a little more
practical.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine <[email protected]> wrote:

> Derick Rethans wrote:
>
>> Actually, Kalle just pointed out that it compiles just fine. In that
>> case, I think we should put it in trunk and in the 5.4 alpha.
>>
>
> As long as it is disabled by default and can easily be replaced by
> preferred alternatives ... eaccelerator is still working fine now that it
> has been upgraded to handle 5.3 ... although it would be nice to see some
> more up to date comparisons. Although I suspect in reality, the combination
> with database and other caching activity means that a straight comparison
> may be a little meaningless? Change the database and the figures are going
> to be different anyway ... so a straight comparison on non-database code
> would be a little more practical.
>

+1. Being disabled by default was agreed on for "old 6.x" so should be for
5.4 as well.

However I think there probably is a lot of possibilities for PHP if it was
better integrated in the future (lets say "new 6.x").
To offer better autoload performance if you stick to PSR-0 for class
autoloading for instance. Hence a future php version that has better
persistent knowledge of classes used on the system so every class load
doesn't result in a full require call with all its overhead on every
request.
And/Or a shared api / backend for shared persistent cache for stat calls,
real path and parsed php structures, and anything else one might want to let
persist between requests in the future.
A discussion for another thread some other time off course.




> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

+1 to adding APC to trunk, it does compile fine (at least at the moment).

On Mon, Nov 1, 2010 at 3:34 PM, Derick Rethans <d[email protected]> wrote:
> Hi!
>
> I understand that the general idea is to bundle APC with a future
> version of PHP. Right now, APC doesn't really compile for trunk because
> of internal changes. However, for PHP 5.3 it's getting into a pretty
> good shape. In order to add APC, what does still need to be done?
>
> cheers,
> Derick
>
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

We should probably stick with the bison parser for now, at least until
the lemon matches the speed of the existing solution.

On Mon, Nov 1, 2010 at 3:41 PM, Etienne Kneuss <[email protected]> wrote:
> On Nov 01 15:33:59, Derick Rethans wrote:
>> Hi!
>>
>> Work has been done on rewriting the PHP parser to Lemon in a specific
>> branch: http://svn.php.net/viewvc/php/php-src/branches/LEMON/
>>
>> Right now, the Lemon parser is not actually faster than the current
>> bison parser, so I would suggest not to put this in PHP 5.4 until it
>> performs at least as well as the current parser.
>>
>> Are there any possibilities for optimisation so far?
>
> I'd make the guess that it is slower due to the rule decomposition that
> we had to do to match bison's "mid-rules" syntax.
>
> We could surely optimize the decomposition but it would require a lot of
> rewrite in zend_compile.c, which is quite tricky to do.
>
>>
>> cheers,
>> Derick
>>
>> --
>> http://derickrethans.nl | http://xdebug.org
>> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
>> twitter: @derickr and @xdebug
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> --
> Etienne Kneuss
> http://www.colder.ch
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 11/02/2010 10:31 AM, Ilia Alshanetsky wrote:
> We should probably stick with the bison parser for now, at least until
> the lemon matches the speed of the existing solution.

+1

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Nov 2, 2010, at 9:13, "André Rømcke" <[email protected]> wrote:

> On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine <[email protected]> wrote:
>
>> Derick Rethans wrote:
>>
>>> Actually, Kalle just pointed out that it compiles just fine. In that
>>> case, I think we should put it in trunk and in the 5.4 alpha.
>>>
>>
>> As long as it is disabled by default and can easily be replaced by
>> preferred alternatives ... eaccelerator is still working fine now that it
>> has been upgraded to handle 5.3 ... although it would be nice to see some
>> more up to date comparisons. Although I suspect in reality, the combination
>> with database and other caching activity means that a straight comparison
>> may be a little meaningless? Change the database and the figures are going
>> to be different anyway ... so a straight comparison on non-database code
>> would be a little more practical.
>>
>
> +1. Being disabled by default was agreed on for "old 6.x" so should be for
> 5.4 as well.

+1

As long as it actually works as opposed to just compiling :)

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Nov 2, 2010, at 10:43, "Ilia Alshanetsky" <[email protected]> wrote:

> We should probably stick with the bison parser for now, at least until
> the lemon matches the speed of the existing solution.
>
+1, and there should also be some clear advantages for making the switch and introducing risk even once it's fast enough (not saying there aren't!)

Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Nov 2, 2010 at 7:14 PM, Zeev Suraski <[email protected]> wrote:

> On Nov 2, 2010, at 9:13, "André Rømcke" <[email protected]> wrote:
>
> > On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine <[email protected]> wrote:
> >
> >> Derick Rethans wrote:
> >>
> >>> Actually, Kalle just pointed out that it compiles just fine. In that
> >>> case, I think we should put it in trunk and in the 5.4 alpha.
> >>>
> >>
> >> As long as it is disabled by default and can easily be replaced by
> >> preferred alternatives ... eaccelerator is still working fine now that
> it
> >> has been upgraded to handle 5.3 ... although it would be nice to see
> some
> >> more up to date comparisons. Although I suspect in reality, the
> combination
> >> with database and other caching activity means that a straight
> comparison
> >> may be a little meaningless? Change the database and the figures are
> going
> >> to be different anyway ... so a straight comparison on non-database code
> >> would be a little more practical.
> >>
> >
> > +1. Being disabled by default was agreed on for "old 6.x" so should be
> for
> > 5.4 as well.
>
> +1
>
> As long as it actually works as opposed to just compiling :)
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi.

I think there were 2 open question when the APC merge was brought to the
list:
- Which branch should be merged? From the past and current emails, I think
we are talking about the current trunk.
- Should APC be enabled by default?

If APC would be disabled by default, and the current trunk works, then I
would +1 for the inclusion.
However I think that the original thread is about the current status, and
the possible problems.

Tyrael

On Tue, Nov 2, 2010 at 7:14 PM, Zeev Suraski <[email protected]> wrote:

> As long as it actually works as opposed to just compiling :)

It builds, whether it works as of now with trunk is another question.

But that's something we can test in the next couple of weeks before
its inclusion in trunk.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php