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
hi Anthony,
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara 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 review and do t
On Sat, Jan 26, 2013 at 9:26 AM, Anthony Ferrara 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 review and do the
> > chang
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 Fri, Jan 25, 2013 at 8:05 PM, Pierre Joye wrote:
> On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf
> 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.
> >
> > Commi
On Fri, Jan 25, 2013 at 7:53 PM, Rasmus Lerdorf 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 5.5 branch
On Fri, Jan 25, 2013 at 7:48 PM, Zeev Suraski 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:
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
> -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
>
> -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,
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
hi Zeev,
On Fri, Jan 25, 2013 at 5:25 PM, Zeev Suraski 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
> @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
On Jan 25, 2013, at 11:52 AM, Julien Pauli wrote:
> On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch wrote:
>
> On Jan 25, 2013, at 11:25 AM, Zeev Suraski wrote:
>
> >> Either by a number of people stepping up to help with the existing APC
> > code, or
> >> perhaps more realistically making it a
> -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/201
> 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: 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
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
On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch wrote:
>
> On Jan 25, 2013, at 11:25 AM, Zeev Suraski 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 an
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 Jan 25, 2013, at 11:25 AM, Zeev Suraski 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
> heavily
> 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 thin
> 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
On 1/25/2013 4:37 AM, Julien Pauli wrote:
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf 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 and blindfolded. I
> 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 wrote:
>
>
>
> 2013/1/25 Thomas Bley
>>
>
2013/1/25 Thomas Bley
> > 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 so
> 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 performanc
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf 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 challeng
On Jan 25, 2013 9:19 AM, "Rasmus Lerdorf" 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 opcode cachi
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 mak
> 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
> necess
On Fri, Jan 25, 2013 at 1:22 AM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2013/1/24 David Soria Parra :
> > 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 ye
Hi
2013/1/24 David Soria Parra :
> 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:
http://www
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 features
34 matches
Mail list logo
