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
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
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,
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--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
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
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--
--
Etienne Kneuss
http://www.colder.ch
We should probably stick with the bison parser for now, at least until
the lemon matches the speed of the existing solution.
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--
--
Etienne Kneuss
http://www.colder.ch
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/
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
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
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
2010/11/2 Derick Rethans derick@php.net:
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--
--
Patrick Allaert
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
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
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 - G8HFLContact - 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
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
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
--
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
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
+1 to adding APC to trunk, it does compile fine (at least at the moment).
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
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
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.