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,
2013/2/28 Jens Riisom Schultz ibmu...@me.com
Hi everyone,
(I got hooked off this discussion, so I have tried to keep up by reading
the digest... This makes it impossible for me to correctly interleave my
comments, so I'll just top post or whatever the term is) (I'm sure this
has been
-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
Hello,
please read my comment inline...
2013/2/28 Sebastian Krebs krebs@gmail.com
2013/2/28 Jens Riisom Schultz ibmu...@me.com
Hi everyone,
(I got hooked off this discussion, so I have tried to keep up by
reading
the digest... This makes it impossible for me to correctly
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
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 release 5.5 without a good solution for that problem, would not
make the situation
Hi,
yesterday, I submitted a patch to add a batch modification function to the
LDAP extension:
https://bugs.php.net/bug.php?id=64317
IMNSHO, this would be a very useful addition to PHP’s LDAP API (and I think
the submitter of bug 31209, among others, would agree with me), so I’d like
to ignite
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
Please kill that alias. It is pointless to introduce a new function
with an alias for it.
I killed the alias in this commit:
https://github.com/ramsey/php-src/commit/3439a098a0b646ff05d4da9748996214cac39d12
-Ben
Hi Jens,
I see two problems with your proposal:
For example the following class, namespace Framework; internal
class Something {}, would only be visible from within the Framework
namespace.
What about classes in a sub-namespace of Framework? Will classes in
\Framework\Foo have access to
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 02/28/2013 05:54 AM, Ondřej Hošek wrote:
Hi,
yesterday, I submitted a patch to add a batch modification function to the
LDAP extension:
https://bugs.php.net/bug.php?id=64317
IMNSHO, this would be a very useful addition to PHP’s LDAP API (and I think
the submitter of bug 31209, among
Hey all,
Based off of the recent discussion around pulling in ZO+ into core, I've
come to the conclusion that we should also pull in XDebug and Suhosin into
core at the same time.
1. It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini
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
Hi!
Based off of the recent discussion around pulling in ZO+ into core, I've
come to the conclusion that we should also pull in XDebug and Suhosin into
core at the same time.
Suhosin has multiple BC-incompatible and performance-problematic changes
and limits and the author refused many times
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
[...]
Sorry, but I hope you are in some funny sort of mood...
Mike
Hi,
On Thu, Feb 28, 2013 at 8:37 PM, Christopher Jones
christopher.jo...@oracle.com wrote:
This should have an RFC sooner rather than later. See
https://wiki.php.net/rfc
Alright. It kinda looked like that RFCs are only for core language
features, so I wrote to the mailing list instead, but
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,
Setting aside difficulty of implementation, I'm coming around to the idea, though I think
you could simplify it by cordoning off an entire namespace. E.g.:
A namespace at least two deep (e.g. \A\B\) may be marked 'protected' (by some method TBD).
Classes and functions declared in a protected
On Thu, 28 Feb 2013, Anthony Ferrara wrote:
Based off of the recent discussion around pulling in ZO+ into core,
I've come to the conclusion that we should also pull in XDebug and
Suhosin into core at the same time.
Suhosin has a large performance impact (even the normal patch, without
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
Derick:
On Thu, Feb 28, 2013 at 3:39 PM, Derick Rethans der...@php.net wrote:
On Thu, 28 Feb 2013, Anthony Ferrara wrote:
Based off of the recent discussion around pulling in ZO+ into core,
I've come to the conclusion that we should also pull in XDebug and
Suhosin into core at the same
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
On Thu, 28 Feb 2013, Anthony Ferrara wrote:
It appears that xdebug is borking generator exception handling. Without
xdebug the following two tests pass, but with it they fail:
Generator::throw() where the exception is caught in the generator
[Zend/tests/generators/throw_caught.phpt]
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 3:00 PM, Anthony Ferrara ircmax...@gmail.com wrote:
1. It has integration issues with ZO+ in that it has to be included in a
specific order (specifically around ini declarations). If it was included
into core, this could be accounted for allowing for more robust
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.
On Feb 28, 2013, at 5:59 PM, Fabian Becker half...@xnorfz.de wrote:
Hi Jens,
I see two problems with your proposal:
For example the following class, namespace Framework; internal class
Something {}, would only be visible from within the Framework namespace.
What about classes in a
Setting aside difficulty of implementation, I'm coming around to the idea,
though I think you could simplify it by cordoning off an entire namespace.
E.g.:
A namespace at least two deep (e.g. \A\B\) may be marked 'protected' (by some
method TBD). Classes and functions declared in a
Hi!
Due to the fixes to CVE-2013-1635 and CVE-2013-1643 we're releasing PHP
5.4.13 RC1 and PHP 5.3.23 RC1 for testing a bit earlier. Both releases
can be found at:
http://downloads.php.net/stas/
Windows binaries will be available at:
http://windows.php.net/qa/
Please test this release and
70 matches
Mail list logo
