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 notify
> 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
On Feb 28, 2013, at 5:59 PM, Fabian Becker 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 sub-n
On Feb 28, 2013 9:16 PM, "Zeev Suraski" 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 8:16 PM, "Ilia Alshanetsky" 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 cases from st
On 01/03/2013, at 9:22 AM, Jan Ehrhardt 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 the cont
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 pul
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
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 b
On Thu, Feb 28, 2013 at 11:47 PM, Anthony Ferrara 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 custom for
On Thu, Feb 28, 2013 at 3:00 PM, Anthony Ferrara 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 behavior.
I don't use Su
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 b
>> 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
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 vers
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]
>
On Thu, Feb 28, 2013 at 11:37 PM, Levi Morrison 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 many machines withou
> 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
> 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 w
On Thu, Feb 28, 2013 at 10:27 PM, Rasmus Lerdorf 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 compati
Derick:
On Thu, Feb 28, 2013 at 3:39 PM, Derick Rethans 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 time.
>
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 pr
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 che
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
tu
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 na
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 f
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,
[...]
Sorry, but I hope you are in some funny sort of mood...
Mike
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 to
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 time
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
no
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 th
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 decl
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 other
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 coul
On Thu, Feb 28, 2013 at 8:13 PM, Stas Malyshev wrote:
> 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 ne
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 p
>> 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 wi
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 wi
>>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 stab
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 w
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
On Feb 28, 2013 7:56 PM, "Ilia Alshanetsky" 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 from their cu
> 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 c
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 performance
On 02/28/2013 10:37 AM, Nikita Popov wrote:
> On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski 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
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski 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 of new
cod
On Thu, Feb 28, 2013 at 6:58 PM, Zeev Suraski 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 not in
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 if&when we do propose to integrate it more tightly -
it's debat
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski 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 - PHP Runtime
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
On 28 בפבר 2013, at 19:33, Nikita Popov wrote:
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
> Based on the overwhelming response, the vote is now open J
>
>
>
> https://wiki.php.net/rfc/optimizerplus
>
>
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski 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
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
> 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
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 reas
> -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 Ilia,
On Thu, Feb 28, 2013 at 2:54 PM, Ilia Alshanetsky 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 release 5.5 wi
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 cou
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
Ilia,
On Thu, Feb 28, 2013 at 8:54 AM, Ilia Alshanetsky 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 release 5.5 wit
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 a
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 better,
hi Zeev,
On Thu, Feb 28, 2013 at 2:06 PM, Zeev Suraski 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 versions.
> 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 u
On Thu, Feb 28, 2013 at 11:21 AM, Zeev Suraski 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
> 125550 P
Hello,
please read my comment inline...
2013/2/28 Sebastian Krebs
> 2013/2/28 Jens Riisom Schultz
>
> > 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, s
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
>di
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 bu
> -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
>
>
2013/2/28 Jens Riisom Schultz
> 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 mentioned b
Den 28/02/2013 kl. 07.53 skrev Pierre Joye :
>
> 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, while it is temptin
70 matches
Mail list logo
