Pierre et al,
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do the
changes more easily.
Well, I think the one issue with doing it in PECL
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara ircmax...@gmail.comwrote:
Pierre et al,
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can review and do
hi Anthony,
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Pierre et al,
I would prefer to have it in pecl and merge once ready/cleaned up.
Yes, same idea than with APC, except that it could be faster (for what
I read, waiting to see the sources). Also we can
Hello,
I'm not sure if it could be considered as a feature but what about these
RFCs:
https://wiki.php.net/rfc/error-optimizations
https://wiki.php.net/rfc/grisu3-strtod
Some of them have been opened for some time now.
Also, wouldn't a cleanup of the current RFC listed for PHP help out in the
On 01/24/2013 11:56 PM, Ralf Lang wrote:
From what I understood from Rasmus the biggest challenge with merging APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's
On Jan 25, 2013 9:19 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/24/2013 11:56 PM, Ralf Lang wrote:
Either by a number of people stepping up to help with the existing APC
code, or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/24/2013 11:56 PM, Ralf Lang wrote:
From what I understood from Rasmus the biggest challenge with merging
APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
I think it is fine if APC doesn't support all features of PHP. When
there is a clear documentation, everybody can decide if he skips some
features for better
2013/1/25 Thomas Bley thbley+...@gmail.com
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
I think it is fine if APC doesn't support all features of PHP. When
there is a clear documentation, everybody can decide
You cannot simply decide
if you cannot decide, you can run tests or turn it off. Having it off
by default would be the same as today.
Most people activate apc without further thinking.
Regards,
Thomas
On Fri, Jan 25, 2013 at 1:15 PM, Sebastian Krebs krebs@gmail.com wrote:
2013/1/25
On 1/25/2013 4:37 AM, Julien Pauli wrote:
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
And I can understand the lack of help. It is probably the most
complicated piece of the entire stack. It is a an op_array juggler doing
a complex dance on a tight rope backwards
One thing I can guarantee is that if we add it to core in its current
condition it will delay 5.5 by 6+ months if not longer.
I am not familiar with the details of opcodes at all, let alone APC.
However, I think it would be wise to delay major core changes for APC
until the next major version
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
heavily
simplified version of APC or writing a new one.
One thing I
On Jan 25, 2013, at 11:25 AM, Zeev Suraski z...@zend.com wrote:
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either including a
On Fri, 25 Jan 2013, Rasmus Lerdorf wrote:
…or perhaps more realistically making it a priority in PHP 5.6 to
streamline the engine and the executor for opcode caching and either
including a heavily simplified version of APC or writing a new one.
I think that's probably one of the key points
On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch willfi...@php.net wrote:
On Jan 25, 2013, at 11:25 AM, Zeev Suraski z...@zend.com wrote:
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
On 01/25/2013 08:25 AM, Zeev Suraski wrote:
There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to
-Original Message-
From: Will Fitch [mailto:wfi...@meetme.com] On Behalf Of Will Fitch
Sent: Friday, January 25, 2013 6:48 PM
To: Zeev Suraski; Rasmus Lerdorf
Cc: Ralf Lang; internals@lists.php.net
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On Jan 25
Any software written to make use of that already has
conditional checks around it plus that feature needs a serious re-think
anyway.
FWIW, we only deploy with APC, so we don't necessarily have checks guarding
apc_fetch()/apc_store().
That said, it would be trivial to write wrapper functions
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Friday, January 25, 2013 7:16 PM
To: Zeev Suraski
Cc: Ralf Lang; internals@lists.php.net
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
On 01/25/2013 08:25 AM, Zeev Suraski wrote
On Jan 25, 2013, at 11:52 AM, Julien Pauli jpa...@php.net wrote:
On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch willfi...@php.net wrote:
On Jan 25, 2013, at 11:25 AM, Zeev Suraski z...@zend.com wrote:
Either by a number of people stepping up to help with the existing APC
code, or
@Zeev, is anyone writing up an RFC for this?
Not yet, I'll write one.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi Zeev,
On Fri, Jan 25, 2013 at 5:25 PM, Zeev Suraski z...@zend.com wrote:
Either by a number of people stepping up to help with the existing APC
code, or
perhaps more realistically making it a priority in PHP 5.6 to streamline
the
engine and the executor for opcode caching and either
Hi!
There's another option. We have the Optimizer+ component which is
current, a bit faster than APC, worked with PHP 5.4 from the get go and
already fully supports 5.5 - and now that it's been free for use for
several years, we'd actually be happy to opensource it and make it a part
of
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Friday, January 25, 2013 8:42 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Ralf Lang; PHP internals
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
hi Zeev,
On Fri, Jan 25, 2013 at 5:25 PM
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Friday, January 25, 2013 8:45 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Ralf Lang; internals@lists.php.net
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
Hi!
There's another option
On 01/25/2013 10:49 AM, Zeev Suraski wrote:
Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually making it happen.
Commit to master maybe and we can work on cleaning it up for the 5.5 branch.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing
On Fri, Jan 25, 2013 at 7:48 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Friday, January 25, 2013 8:42 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Ralf Lang; PHP internals
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature
On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/25/2013 10:49 AM, Zeev Suraski wrote:
Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually making it happen.
Commit to master maybe and we can work on cleaning it up for the
On Fri, Jan 25, 2013 at 8:05 PM, Pierre Joye pierre@gmail.com wrote:
On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 01/25/2013 10:49 AM, Zeev Suraski wrote:
Ok, I'll write up an RFC, and in parallel we'll try to figure out the
mechanics of actually
Hi Internals,
as you might have read in the 5.5.0alpha4 announcments, we are moving
forward with 5.5.0. We are already a bit late on the schedule and
we want to begin the beta cycle in 14 days and concentrate on QA
for the 5.5.0 release from now on.
This includes a feature freeze. No new
Hi
2013/1/24 David Soria Parra d...@php.net:
This includes a feature freeze. No new features should be comitted to
the repository once we tagged the first beta on Feb 7. All outstanding
features will have to wait for 5.6.0 in a year unless there is a
This reminds me of yet another old topic:
On Fri, Jan 25, 2013 at 1:22 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Hi
2013/1/24 David Soria Parra d...@php.net:
This includes a feature freeze. No new features should be comitted to
the repository once we tagged the first beta on Feb 7. All outstanding
features will have to wait
From what I understood from Rasmus the biggest challenge with merging APC
into core is the fact that the compiler currently isn't built to support
opcode caching. One of the challenges he pointed out was some of the
MAKE_NOP trickery that can make APC's work a bit more complex than
necessary.
34 matches
Mail list logo
