On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans a...@zend.com wrote:
The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this feature. The split is the
timing.
On Thu, Mar 7, 2013 at 10:00 PM, David Soria Parra d...@php.net wrote:
I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.
I disagree that it is the only point
On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans a...@zend.com wrote:
The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this feature. The split is the
timing.
-Original Message-
From: Rafael Dohms [mailto:lis...@rafaeldohms.com.br]
Sent: Friday, March 08, 2013 2:52 PM
To: Andi Gutmans
Cc: Anthony Ferrara; Philip Olson; David Soria Parra; PHP internals
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
I'm right now oblivious to what is being voted or not in this case,
but ignoring a defined 2/3 rule is clearly wrong. Either remove rules or
follow them otherwise they become useless noise.
As far as I understand the RFC is a process to accept or reject features.
The question that falls in
On Sun, Mar 3, 2013 at 10:23 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/03/2013 12:43 AM, Pierre Joye wrote:
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
The
first step towards integration is getting it in.
That does not guarantee that further steps
] Integrating Zend Optimizer+ into the PHP
distribution
On Sun, Mar 3, 2013 at 10:23 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/03/2013 12:43 AM, Pierre Joye wrote:
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
The
first step towards integration is getting
On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski z...@zend.com wrote:
Nikita,
The 1-2 month estimation, is taken from about 50cm behind the fingers
typing this email, aka my gut J. It’s quite possible it’ll take much
less, or no time at all; But it’s possible that once we include it, a lot
hi,
On Thu, Mar 7, 2013 at 5:01 PM, Nikita Popov nikita@gmail.com wrote:
The majority yes. The accessors proposal also had the majority in favor,
but that did not suffice. As of now this RFC does *not* have a 2/3 majority
for the delay. And, as I already pointed out, I really think that
On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski z...@zend.com wrote:
Nikita,
The 1-2 month estimation, is taken from about 50cm behind the fingers typing
this email, aka my gut J. It’s quite possible it’ll take much less, or no
time at all; But it’s possible that once we include it, a lot
On 03/07/2013 08:26 AM, Pierre Joye wrote:
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.
We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues.
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/07/2013 08:26 AM, Pierre Joye wrote:
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.
We already covered that. An opcode cache
Rasmus,
We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is major or not, doesn't matter per the established
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/07/2013 08:26 AM, Pierre Joye wrote:
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.
We already covered that. An opcode cache
...@gmail.com]
*Sent:* Thursday, March 07, 2013 6:44 PM
*To:* Rasmus Lerdorf
*Cc:* Pierre Joye; Nikita Popov; Zeev Suraski; Laruence; PHP Developers
Mailing List
*Subject:* Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Rasmus,
We already covered that. An opcode cache
On Thu, Mar 7, 2013 at 5:26 PM, Pierre Joye pierre@gmail.com wrote:
what takes longer is to stabilize it, there is no integration work
being done right now, as far as I can tell. Latest issues spotted in
our tests are visible in the report #63472.
I mean #64372
--
Pierre
@pierrejoye
On Thu, Mar 7, 2013 at 5:46 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/07/2013 08:26 AM, Pierre Joye wrote:
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until
Zeev,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.
How do I know? I asked for this special majority in the first place. It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural
On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to if it
classifies as a language change or not... Better to clarify for the
health of the project than to plow through and
PM
*To:* Zeev Suraski
*Cc:* Rasmus Lerdorf; Nikita Popov; Laruence; PHP Developers Mailing List
*Subject:* Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Zeev,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.
How do I know? I
On Thu, Mar 7, 2013 at 6:18 PM, Zeev Suraski z...@zend.com wrote:
94% of the votes voted in favor of integrating O+ into PHP, which is well
above 2/3, it’s almost 3/3.
44 for 5.5 + delay
22 for no delay (aka 5.6)
4 for not at all in the current sate
Sorry but don't use numbers badly to
Yay!
Am 07.03.2013 um 17:48 schrieb Zeev Suraski z...@zend.com:
The voting period ended, and the option selected with 44 out of 70 votes
was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor
delay. An overwhelming majority (66 out of the 70 votes) was in favor of
going with
On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to if it
classifies as a language change or not... Better to clarify
On Mar 7, 2013, at 1:00 PM, David Soria Parra d...@php.net wrote:
On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as
On 7 במרץ 2013, at 23:00, David Soria Parra d...@php.net wrote:
On 2013-03-07, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to
On 03/07/2013 10:33 PM, Philip Olson wrote:
I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.
Shouldn't we be focusing on how this makes PHP better? And not nitpick
Philip,
Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?
I think the point of this
On Thu, Mar 7, 2013 at 9:58 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?
94% voted to integrate ZO+.
Either we stick to the rules, or
On Mar 7, 2013, at 1:58 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Philip,
Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, March 07, 2013 1:58 PM
To: Philip Olson
Cc: David Soria Parra; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Philip,
Shouldn't we
Hi Zeev,
Am 28.02.2013 um 21:16 schrieb Zeev Suraski z...@zend.com:
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.
That’s not entirely true. If you stay as similar as possible
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.
That’s not entirely true. If you stay as similar as possible to your
production environment, your development environment will
-Original Message-
From: Lars Strojny [mailto:l...@strojny.net]
Sent: Tuesday, March 05, 2013 12:31 AM
To: Zeev Suraski
Cc: Anthony Ferrara; Nikita Popov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Hi Zeev,
Am
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
The RFC is about integrating O+ into PHP which can by definition only
happen in 5.5 and later.
Implicitly no, while it is clear that it has to be done. But
explicitly the RFC uses the word integration for 5.5 and it won't
On 03/03/2013 12:43 AM, Pierre Joye wrote:
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
The
first step towards integration is getting it in.
That does not guarantee that further steps can be done, from a timely manner.
There is never any such guarantee and the
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Sunday, March 03, 2013 9:26 AM
To: Zeev Suraski
Cc: Laruence; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
On Sun, Mar 3, 2013 at 8:21 AM
On 2013-02-27, Zeev Suraski z...@zend.com wrote:
On 27 2013, at 18:58, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev et al,
I just want to put my justification for the only if no delay vote. I voted
that way because we're already at a significant delay. If this vote was a
month ago
On Thu, Feb 28, 2013 at 2:53 PM, Pierre Joye pierre@gmail.com wrote:
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
ok, given the total lack
hi Zeev,
On Sun, Mar 3, 2013 at 8:02 AM, Zeev Suraski z...@zend.com wrote:
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
+1,
there should
How Don't integrate Optimizer+ to PHP can be remotely related to the
available of o+ via PECL?
Actually it seems as if some of the original text got lost when I switched
to the active vote, but it used to read 'Don't integrate Optimizer+ to
PHP, release only in PECL'. My bad.
Zeev
--
PHP
On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote:
How Don't integrate Optimizer+ to PHP can be remotely related to the
available of o+ via PECL?
Actually it seems as if some of the original text got lost when I switched
to the active vote, but it used to read 'Don't integrate
On 03/02/2013 11:25 PM, Pierre Joye wrote:
On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote:
How Don't integrate Optimizer+ to PHP can be remotely related to the
available of o+ via PECL?
Actually it seems as if some of the original text got lost when I switched
to the active
On 02/28/2013 02:34 PM, Anthony Ferrara wrote:
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
I tested PHPUnit with both Xdebug and ZO+ enabled and got a correct
code coverage report. So at least that
Den 28/02/2013 kl. 07.53 skrev Pierre Joye pierre@gmail.com:
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
My reasons exactly for now,
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Now
Hi,
Am 02/28/2013 11:21 AM, schrieb Zeev Suraski:
I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:
481004 PHP/5.2.17
280342 PHP/5.3.8
you can add another ~100 PHP/5.3.8 installations.
For our company stability and bug
Zeev Suraski wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
On Thu, Feb 28, 2013 at 11:21 AM, Zeev Suraski z...@zend.com wrote:
I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:
481004 PHP/5.2.17
280342 PHP/5.3.8
271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
133818 PHP/5.2.6
This is amazing how you take every single opportunity to bash the new
release
process, forgetting all pro arguments that have been brought in the last
discussions.
I'm not bashing it. I think the process is good. I'm saying the
frequency is wrong and doesn't suit the needs of most of our
hi Zeev,
On Thu, Feb 28, 2013 at 2:06 PM, Zeev Suraski z...@zend.com wrote:
Most users don't upgrade because they don't need the new features and
can't be bothered to upgrade.
There's no such thing as 100% downwards compatibility, and 5.5 will be no
different in that sense from previous
Suraski z...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
Ilia,
On Thu, Feb 28, 2013 at 8:54 AM, Ilia Alshanetsky i...@prohost.org wrote:
Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To
On 28.02.2013 11:47, Frank Schenk wrote:
For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of days work for each project
to evaluate and migrate to 5.4.x
I
Jordi Boggiano in php.internals (Thu, 28 Feb 2013 15:33:06 +0100):
On 28.02.2013 11:47, Frank Schenk wrote:
For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of
hi Ilia,
On Thu, Feb 28, 2013 at 2:54 PM, Ilia Alshanetsky i...@prohost.org wrote:
Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Thursday, February 28, 2013 3:12 PM
To: Zeev Suraski
Cc: Ferenc Kovacs; Rasmus Lerdorf; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
hi Zeev
Zeev Suraski wrote:
Of course I do, but I would say that saying 5.4 is 'extremely incompatible
with 5.3' is also nitpicking. Which is why I doubt 5.5 will see
dramatically different adoption rates from 5.4. If anything, having O+
inside 5.5 would help - although personally I think that the
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
What kind of majority does this vote require? 50% or 2/3?
Thanks,
Nikita
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
On 28 בפבר 2013, at 19:33, Nikita Popov nikita@gmail.com wrote:
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:
Based on the overwhelming response, the vote is now open J
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:
No syntax changes, so regular majority as far as I can tell.
Except if you want real integration included in this vote, as it will
or may affect the engine, 2/3 will be required then.
--
Pierre
@pierrejoye
--
PHP Internals -
No.
First, read what 'integration' means in the RFC or in the excerpt
Chris was nice enough to send you. It means including the extension,
which doesn't fall under changing the language in the voting RFC in
any way.
Secondly, even ifwhen we do propose to integrate it more tightly -
it's
On Thu, Feb 28, 2013 at 6:58 PM, Zeev Suraski z...@zend.com wrote:
No.
First, read what 'integration' means in the RFC or in the excerpt
Chris was nice enough to send you. It means including the extension,
which doesn't fall under changing the language in the voting RFC in
any way.
That's
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount
On 02/28/2013 10:37 AM, Nikita Popov wrote:
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski z...@zend.com wrote:
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.
My take on this is that we integrate O+ in to core, iron out all the issues
and then release a stable 5.5.
If O+ will improve the
To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4
was. Today, right now, there exists at least one stable open source opcode
cache. 5.4 had none for many months after release. So I'm not sure if the
same pressures exist.
If you are referring to APC as the stable
On Feb 28, 2013 7:56 PM, Ilia Alshanetsky i...@prohost.org wrote:
Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade
Hi!
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount of new
code that is close to the engine. People doing engine changes will need to
modify it too (thus it is quasi part of the engine, even if it
Ilia,
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with
Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.
If we get to get it stable in a
Hi!
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC,
The APC issues are somewhat APC specific in most cases, they often
revolve around memory utilization issues and garbage collection. Some
of the work-arounds involve ensuring APC always has extra memory to
prevent fragmentation. When fragmentation goes about 35-40% clearing
out the entire cache to
On Thu, Feb 28, 2013 at 8:13 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
It's not a syntax change, but it is a very, very large engine change.
Yes,
it does not touch the Zend engine itself, but it adds a large amount of
new
code that is close to the engine. People doing engine
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
And some
On Thu, 28 Feb 2013, Anthony Ferrara wrote:
However, it does nuke several existing PECL extensions (some fatally).
For example, XDebug has no compatibility with ZendOptimizer+ right now
(at least that I could find, feel free to correct me if I'm wrong
here).
You wouldn't want to run them
Hi!
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
This of course will have to be fixed before the release. Though right
now
It shouldn't kill any PECL extensions, most certainly not Xdebug.
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.
Either way - in the long run O+ and Xdebug will *definitely* work
On 02/28/2013 11:34 AM, Anthony Ferrara wrote:
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find,
Hi!
It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currently
Could you describe the bad things? Maybe we could have some checks in
either of them to prevent it... Of course, we could probably make ZO
just
On 02/28/2013 12:49 PM, Stas Malyshev wrote:
Hi!
It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currently
Could you describe the bad things? Maybe we could have some checks in
either of them to prevent
On Thu, Feb 28, 2013 at 10:27 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/28/2013 11:34 AM, Anthony Ferrara wrote:
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no
I've read all the e-mails so far and there are valid points from both
parts but it seems there's a critical thing missing.
What do PHP users want?
I mean, what do sysadmins, programmers and managers want from PHP 5.5?
Here's my personal opinion:
I work in an enterprise so... I want
A huge, out of the box, speed bump for production machines.
For some applications PHP 5.4 was a huge speed bump out of the box . . .
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Feb 28, 2013 at 11:37 PM, Levi Morrison morrison.l...@gmail.com wrote:
A huge, out of the box, speed bump for production machines.
For some applications PHP 5.4 was a huge speed bump out of the box . . .
Would you run PHP against 10k+ req/s in production without opcode caching?
On how
Florin
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?
I'm not sure about your stack, but every stack I've seen at that high of a
load is built very custom for the problem at hand. And it isn't typically
upgraded across minor
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?
This is getting a bit off-topic now, but all my work is geared towards
tools for users and system administrators in the LAN. We don't need an
op-code cache. We never get more than six
On 28/02/2013 13:54, Ilia Alshanetsky wrote:
The major reason being is the lack of a stable, production ready op-code
cache.
Am I crazy or APC not stable != a lack of a stable opcode cache. Whole
discussion thread has been assuming people don't use anything and or
there's nothing better than
On Thu, Feb 28, 2013 at 11:47 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Florin
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?
I'm not sure about your stack, but every stack I've seen at that high of a
load is built very
Stas,
Just to put things in perspective, if opcode caches with extended info
make it into the opcode cache - it's a bad thing. So it's actually
expected that debuggers and opcode caches would have to be aware of
one another, but at a pretty minimal level. The load order solves it
most probably
Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.
On the contrary: many users will welcome it because it delays the EOL of
Hi!
Just to put things in perspective, if opcode caches with extended info
make it into the opcode cache - it's a bad thing. So it's actually
Yeah, we should definitely check for extended info and shortcut
compile_file immediately if that is there. Should be an easy patch, I'll
try to do pull
On 01/03/2013, at 9:22 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.
On Feb 28, 2013 8:16 PM, Ilia Alshanetsky i...@prohost.org wrote:
If ZO+ was a brand new code, I'd agree with you 100%. However, it is
an existing solution that has been used in a wild in quite some time
an limited empirical evidence shows that it works somewhat better than
APC in most
On Feb 28, 2013 9:16 PM, Zeev Suraski z...@zend.com wrote:
It shouldn't kill any PECL extensions, most certainly not Xdebug.
es (preconditions, post conditionj and invariants)...
And what is the reason to still have no pecl release for o+? It should have
been done a month ago.
+1
On Wed, Feb 27, 2013 at 1:12 PM, Zeev Suraski z...@zend.com wrote:
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
--
Alberto Guimarães Viana
E-mail: albertogvi...@gmail.com
Zeev et al,
I just want to put my justification for the only if no delay vote. I
voted that way because we're already at a significant delay. If this vote
was a month ago when O+ was suggested first, I would definitely have voted
for delay. In fact IIRC I proposed a delay back then. But after a
On 27 בפבר 2013, at 18:58, Anthony Ferrara ircmax...@gmail.com wrote:
Zeev et al,
I just want to put my justification for the only if no delay vote. I voted
that way because we're already at a significant delay. If this vote was a
month ago when O+ was suggested first, I would definitely
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote:
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
Hi Zeev,
I'm not sure that the current options covering all cases.
How should one vote
On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
ps: I really love what you guys did with opensourcing it, but I just think
that it is too late for 5.5 and I think that it is better to stick to the
original roadmap, instead of having a 6 months delay just to ship the O+ in
the core 6months
1 - 100 of 109 matches
Mail list logo
