Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Yasuo Ohgaki]

Hi Dmitry,

On Fri, Jun 10, 2016 at 9:37 PM, Dmitry Stogov  wrote:
> I hardly worked on implementation of this patch for a week, but I still don't 
> like it.
>
> It makes 15% slowdown on each property update in existing PHP code (without 
> types), and I don't see a way to improve this.
>
> Update of typed properties is going to be even more expensive.
>
> Benchmark results are included into RFC (and not changed with the latest 
> version of the patch).
>
>
> -1.

If we are concerned about performance, DbC would be the only solution
for this kind of problem. i.e. Validate fully during development, do
minimum validation on production. DbC helps type inference also. There
may not be enough time for discussion, but do you think there is
enough time for implementation? I suppose implementation is
straightforward, so it might be OK to have RFC w/o implementation. We
have 2 options anyway. It's waste of time for having 2
implementations. Would you like to proceed the RFC for 7.1?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Iterable

[Aaron Piotrowski]

Hello,

I would like to propose a new iterable pseudo-type that accepts both arrays and 
objects implementing Traversable. Values accepted by iterable can then be used 
with foreach and yield from, or help to reduce type-checking logic in general.

Please review the RFC here: https://wiki.php.net/rfc/iterable 


Thanks!

Aaron Piotrowski

[PHP-DEV] Re: [RFC][Vote] Typed Properties

[Benoit Schildknecht]

Hi,

Is it 2/3+1 or 1/2+1 ? I haven't seen it in the RFC.

Cheeers.

Le Fri, 10 Jun 2016 12:38:04 +0200, Joe Watkins  a  
écrit:



Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe



--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][Vote] Typed Properties

[Benjamin Eberlei]

It changes the language, and therefore is 2/3 (without +1 afaik, just 2/3
required).

On Sat, Jun 11, 2016 at 12:09 AM, Benoit Schildknecht 
wrote:

> Hi,
>
> Is it 2/3+1 or 1/2+1 ? I haven't seen it in the RFC.
>
> Cheeers.
>
>
> Le Fri, 10 Jun 2016 12:38:04 +0200, Joe Watkins  a
> écrit:
>
> Afternoon internals,
>>
>> The vote for typed properties has been restarted.
>>
>> Please take part: https://wiki.php.net/rfc/typed-properties
>>
>> Cheers
>> Joe
>>
>
>
> --
> Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Dmitry Stogov]

In general, you are right, but this is possible only if application ignores 
Error exceptions...



From: morrison.l...@gmail.com  on behalf of Levi 
Morrison 
Sent: Friday, June 10, 2016 11:50:26 PM
To: Dmitry Stogov
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

On Fri, Jun 10, 2016 at 2:06 PM, Dmitry Stogov  wrote:
> Hi internals,
>
>
> Please review: https://wiki.php.net/rfc/constant_redefinition
>
>
> Thanks. Dmitry.

Dmitry, I am not sure this change will actually allow constant
propagation either. Consider this code:



In this series of events:

  - Foo is declared to be 0
  - This above file is now included inside a try-catch block that
catches the error
  - FooFactory::make() is now called

If Foo = 1 was propagated then FooFactory::make() will return 1 instead of 0.

Am I missing something?

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 10/06/16 22:05, Larry Garfield wrote:
> 
> https://seld.be/notes/php-versions-stats-2016-1-edition
> 
> The code being written is veering heavily toward newer versions, and
> anecdotally most of the code I see is classed with typed parameters. 
> (Yes, anecdotes are not data, and I acknowledged a likely bias earlier,
> but I'm not sure how to generate actually objective data on this
> front.)  That is arguably a more reliable measure of what developers are
> doing than the W3Techs stats, which are based on what servers are
> running.  (A useful but different metric.)

The problem with your base is it assumes everybody is using composer?
Just how many people are not? None of my infrastructure uses it and none
of the ISP's I support. So it's skewed in favour of the converted.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 03:01 PM, Lester Caine wrote:

On 10/06/16 20:51, Larry Garfield wrote:

On 06/10/2016 02:14 PM, Lester Caine wrote:

On 10/06/16 17:57, Rowan Collins wrote:

For the record, I'm not entirely sure which way I want the language to
go, but I think it's a decision that needs to be made, and soon.

Seconded ... even something like strict mode should be 'removable' to
provide a smaller faster 'classic' PHP even if it does mean there are
two builds. But we already HAVE two builds ... people who want strongly
typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
down the same road map? Each has it's own strengths.

... I am a strong typing proponent (that is a strong proponent of
explicit typing), and have never once used HHVM.  Your claim, that
type-using people can just leave for HHVM, is both nonsensical and untrue.

The same applies to your suggestion that user-land is actively following
you. Getting systems off PHP5.2/3 gets more an more difficult given all
the extra 'little tweaks' that are needed and we still have 40% of users
that need help getting just over to 5.4 let alone up to PHP7. Currently
more people are still using PHP4 than have switched to PHP7 ... so where
is the strong support for typed code?

(https://w3techs.com/technologies/details/pl-php/all/all)


https://seld.be/notes/php-versions-stats-2016-1-edition

The code being written is veering heavily toward newer versions, and 
anecdotally most of the code I see is classed with typed parameters.  
(Yes, anecdotes are not data, and I acknowledged a likely bias earlier, 
but I'm not sure how to generate actually objective data on this 
front.)  That is arguably a more reliable measure of what developers are 
doing than the W3Techs stats, which are based on what servers are 
running.  (A useful but different metric.)


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Levi Morrison]

On Fri, Jun 10, 2016 at 2:06 PM, Dmitry Stogov  wrote:
> Hi internals,
>
>
> Please review: https://wiki.php.net/rfc/constant_redefinition
>
>
> Thanks. Dmitry.

Dmitry, I am not sure this change will actually allow constant
propagation either. Consider this code:



In this series of events:

  - Foo is declared to be 0
  - This above file is now included inside a try-catch block that
catches the error
  - FooFactory::make() is now called

If Foo = 1 was propagated then FooFactory::make() will return 1 instead of 0.

Am I missing something?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with "Too few arguments" exception

[Sebastian Bergmann]

On 06/06/2016 12:07 PM, Derick Rethans wrote:
>> It's a shame it didn't make it for 7.0, but in my opinion, this should now
>> wait for 8.0.
> I agree with that statement, and hence voted "No".

Same reason I voted no.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition

[Dmitry Stogov]

Hi internals,


Please review: https://wiki.php.net/rfc/constant_redefinition


Thanks. Dmitry.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 10/06/16 20:51, Larry Garfield wrote:
> On 06/10/2016 02:14 PM, Lester Caine wrote:
>> On 10/06/16 17:57, Rowan Collins wrote:
>>> For the record, I'm not entirely sure which way I want the language to
>>> go, but I think it's a decision that needs to be made, and soon.
>> Seconded ... even something like strict mode should be 'removable' to
>> provide a smaller faster 'classic' PHP even if it does mean there are
>> two builds. But we already HAVE two builds ... people who want strongly
>> typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
>> down the same road map? Each has it's own strengths.
> 
> ... I am a strong typing proponent (that is a strong proponent of
> explicit typing), and have never once used HHVM.  Your claim, that
> type-using people can just leave for HHVM, is both nonsensical and untrue.

The same applies to your suggestion that user-land is actively following
you. Getting systems off PHP5.2/3 gets more an more difficult given all
the extra 'little tweaks' that are needed and we still have 40% of users
that need help getting just over to 5.4 let alone up to PHP7. Currently
more people are still using PHP4 than have switched to PHP7 ... so where
is the strong support for typed code?

(https://w3techs.com/technologies/details/pl-php/all/all)

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 02:14 PM, Lester Caine wrote:

On 10/06/16 17:57, Rowan Collins wrote:

For the record, I'm not entirely sure which way I want the language to
go, but I think it's a decision that needs to be made, and soon.

Seconded ... even something like strict mode should be 'removable' to
provide a smaller faster 'classic' PHP even if it does mean there are
two builds. But we already HAVE two builds ... people who want strongly
typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
down the same road map? Each has it's own strengths.


... I am a strong typing proponent (that is a strong proponent of 
explicit typing), and have never once used HHVM.  Your claim, that 
type-using people can just leave for HHVM, is both nonsensical and untrue.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Lester Caine]

On 10/06/16 17:57, Rowan Collins wrote:
> 
> For the record, I'm not entirely sure which way I want the language to
> go, but I think it's a decision that needs to be made, and soon.

Seconded ... even something like strict mode should be 'removable' to
provide a smaller faster 'classic' PHP even if it does mean there are
two builds. But we already HAVE two builds ... people who want strongly
typed and pre-compiled PHP simply use HHVM. There is no need to drag PHP
down the same road map? Each has it's own strengths.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Test

[Lester Caine]

On 10/06/16 09:47, Sherif Ramadan wrote:
> Just testing that the mailing list is still working. Please ignore.
Looks like it started working sometime yesterday. My test message seems
to be lost in the ether ;)
The fact there was a network failure on Virgin since last night means
I'm only just getting email traffic again ... AH there is my test
message ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 11:57 AM, Rowan Collins wrote:

On 10/06/2016 17:16, Larry Garfield wrote:

That seems like a worthwhile trade-off for a <1% performance difference
in a real-world application.


The problem is that the performance hit is felt even for code that 
doesn't "opt in" to this feature. For an application that makes no use 
of the feature, it is all cost and no benefit.


I think PHP is at a cross-roads, and (if you'll forgive the stretched 
analogy) at risk of going off-road and getting stuck in the mud.


Option 1 is that the language remains inherently loose-typed, with a 
few entirely optional features to provide type safety in specific 
cases. If this is the aim, then the optional features should be as 
unobtrusive as possible for the "default" loose-typed approach. Any 
performance hit on untyped properties is a big deal under this 
interpretation.


Option 2 is that the language embraces "gradual typing" as a core 
tenet of the language, with loose typing considered a "fallback". If 
this is the aim, then there should be a coherent roadmap of what the 
type system is going to look like. In this case, performance issues 
might be considered an inevitable cost of improving the language; they 
might also be reduced as the Engine is adapted to implement the roadmap.


Option 1 seems more appealing, because it is easier to get agreement 
for, but if we keep piling on the special cases, we're going to end up 
with the worst of both worlds. I see the technical problems with 
creating a reference to a typed property as a sign of this: we are 
creating more of the frustrating inconsistencies that PHP is infamous 
for, because we're trying to have our cake and eat it.


For the record, I'm not entirely sure which way I want the language to 
go, but I think it's a decision that needs to be made, and soon.


Regards,


This is a very accurate and well-stated assessment.  I agree with the 
possible paths.


From the code I see in the wild, it feels like the gradually/mostly 
typed camp has already won in terms of production code.  Most of the PHP 
Rennaissance-era systems (the stuff that came out in the last 5-6 years 
or so) is class-heavy and as type safe as PHP has allowed, most of the 
time.  The exceptions are the highly functional bits, where the language 
doesn't offer as much support as it does for class-family typing.


There's almost certainly some projecting going on here as I'm a 
mostly-typed fan myself, but my sense is that the PHP user-space 
community has already decided they want a robust typing system they can 
use in most (but not all) cases.  The engine should embrace that and 
catch up, with a well thought-out approach to typing.  If it takes a bit 
longer to get certain features as a result of that attention to a 
coherent roadmap, I am happy to make that trade-off.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Rowan Collins]

On 10/06/2016 17:16, Larry Garfield wrote:

That seems like a worthwhile trade-off for a <1% performance difference
in a real-world application.


The problem is that the performance hit is felt even for code that 
doesn't "opt in" to this feature. For an application that makes no use 
of the feature, it is all cost and no benefit.


I think PHP is at a cross-roads, and (if you'll forgive the stretched 
analogy) at risk of going off-road and getting stuck in the mud.


Option 1 is that the language remains inherently loose-typed, with a few 
entirely optional features to provide type safety in specific cases. If 
this is the aim, then the optional features should be as unobtrusive as 
possible for the "default" loose-typed approach. Any performance hit on 
untyped properties is a big deal under this interpretation.


Option 2 is that the language embraces "gradual typing" as a core tenet 
of the language, with loose typing considered a "fallback". If this is 
the aim, then there should be a coherent roadmap of what the type system 
is going to look like. In this case, performance issues might be 
considered an inevitable cost of improving the language; they might also 
be reduced as the Engine is adapted to implement the roadmap.


Option 1 seems more appealing, because it is easier to get agreement 
for, but if we keep piling on the special cases, we're going to end up 
with the worst of both worlds. I see the technical problems with 
creating a reference to a typed property as a sign of this: we are 
creating more of the frustrating inconsistencies that PHP is infamous 
for, because we're trying to have our cake and eat it.


For the record, I'm not entirely sure which way I want the language to 
go, but I think it's a decision that needs to be made, and soon.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Larry Garfield]

On 06/10/2016 10:01 AM, Dmitry Stogov wrote:



To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

I don't see any big value in this feature.
Most framework access their properties through getters and setters 
anyway.

They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected 
speedup, doesn't make any sense for me.


Thanks. Dmitry.


Needing an explicit getter and setter (and the overhead of the function 
call) just for type checking is a bug this feature would obviate.  If 
the only value of the getter/setter is type safety, then you're better 
off not using them.  (There are other reasons to have getters and 
setters, and I'd still love to see the property accessor RFC reborn, but 
that's a separate issue.)


Additionally, typed properties provides a terser, more self-documenting 
way of communicating the property type and thus expected behavior.  I've 
written several doctrine classes, for instance, that are 5 lines of 
properties and 30 lines of getters/setters/docs boilerplate.  If that 
boilerplate can be reduced or eliminated, that's a win.


It also provides better introspection capabilities for ORMs and similar 
serialization tools.  Yes, in some cases richer data than this RFC 
provides is helpful but not always.  In many cases this would be 
sufficient to build automated safety into automated tools. (ORMs, 
serializers, validators that now don't need to be written at all, etc.)


That seems like a worthwhile trade-off for a <1% performance difference 
in a real-world application.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

On 06/10/2016 05:31 PM, Bob Weinand wrote:

Am 10.06.2016 um 16:24 schrieb Levi Morrison :

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov  wrote:

Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 
cache utilization and the number of executed instructions for a runtime-cached 
ASSIGN_OBJ is very small. Where even 4 additional instructions make significant 
difference.
The current fast-path of ASSIGN_DIM is about 40 instruction, so 15% 
slowdown comes exactly from this additional 4 instructions and 
additional memory read.



The 0.1% slowdown of WP and MW are painting a much more realistic (aka real-world) image. 
And as the RFC writes, "may be caused not by the additional checks but by the worse 
CPU cache utilization, because the size of PHP code was increased on 40KB".


Yes, this is my words :)
  
These micro-benches are really insignificant, especially as it is trivial (in tight loops) to work on a local CV and only assign it later to the property.
they show the effect of the patch on the affected operations, and the 
shown slowdown is significant.
Of course this doesn't affect WP significantly, because the whole 
ASSIGN_OBJ cost in the app is less than 1%.

So  we slowdown this ~1% on ~15% and got ~0.1% cumulative slowdown.

Thanks. Dmitry.



This IMO is really voting no for the wrong reasons...

Bob



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ReflectionType improvements

[Joe Watkins]

Afternoon Levi,

Since communication broke down over the last few days, I'm happy for
you to move forward with the discussion period.

Voting will have to be abbreviated to make everything fit.

Cheers
Joe

On Fri, Jun 10, 2016 at 3:50 PM, Levi Morrison  wrote:

> Now that the mailing list is working again I'd like to propose some
> improvements to the ReflectionType API. We added ReflectionType as
> part of the Return Types RFC. At that time the API was intentionally
> kept minimal to not step on the toes of potential future features
> (such as enum, union and intersection types) with the intention of
> fleshing it out later. As long as the release managers for 7.1 are
> okay with it I'd like to do these improvements now. Shall I move
> forward with an RFC or do you consider this too late?
>
> The proposed API looks like this:
> https://gist.github.com/morrisonlevi/5819a2b8d86561849ee916a7bcbc9c29.
> Notably a `ReflectionClassType` will be returned if possible which has
> a `getClass(): ReflectionClass` method. This has been a commonly
> requested addition and simplifies a common use-case.
>
> I tried to discuss these changes on Reddit to gauge community impact
> but it had few responses:
>
> https://www.reddit.com/r/PHP/comments/4m93s1/i_want_to_enhance_and_break_the_reflectiontype/
> .
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

On 06/10/2016 05:24 PM, Levi Morrison wrote:

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov 
 wrote:


Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe


To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.


I don't see any big value in this feature.
Most framework access object properties through getters and setters anyway.
They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected speedup, 
dosn't make any sense.


Thanks. Dmitry.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

On 06/10/2016 05:24 PM, Levi Morrison wrote:

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov  wrote:

Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

 The vote for typed properties has been restarted.

 Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

I don't see any big value in this feature.
Most framework access their properties through getters and setters anyway.
They can be and should be used to provide type-safe API.
Another level of protection that makes slowdown instead of expected 
speedup, doesn't make any sense for me.


Thanks. Dmitry.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

Woops, no it isn't ... the property is private ...

Cheers
Joe

On Fri, Jun 10, 2016 at 3:42 PM, Joe Watkins  wrote:

> That's a bug ... that should throw ...
>
> Cheers
> Joe
>
> On Fri, Jun 10, 2016 at 3:12 PM, Bob Weinand  wrote:
>
>>
>> Am 10.06.2016 um 16:00 schrieb Niklas Keller :
>>
>> 2016-06-10 15:50 GMT+02:00 Bob Weinand :
>>
>>>
>>> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
>>>
>>>
>>> Top-posting, since I'm taking off now.
>>>
>>> From outside the class, properties are not visible at all, so their types
>>> are un-important from outer scopes.
>>>
>>> echo $foo->bar; is not the same in instance method body or outside of the
>>> class.
>>>
>>> From outside it works just fine and doesn't throw:
>>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties
>>>
>>>
>>> This is an intermittent bug in the implementation.
>>> the RFC is explicitly mentioning that it should throw and throwing also
>>> is the correct behavior here.
>>>
>>
>> I don't think this is and should be a bug. I think it is the right
>> behavior if we choose to throw at all.
>>
>>
>> In this case a definite -1 on the RFC from me. I don't want "surprises"
>> regarding the type if a property is declared to return a certain type.
>>
>> Bob
>>
>
>

[PHP-DEV] ReflectionType improvements

[Levi Morrison]

Now that the mailing list is working again I'd like to propose some
improvements to the ReflectionType API. We added ReflectionType as
part of the Return Types RFC. At that time the API was intentionally
kept minimal to not step on the toes of potential future features
(such as enum, union and intersection types) with the intention of
fleshing it out later. As long as the release managers for 7.1 are
okay with it I'd like to do these improvements now. Shall I move
forward with an RFC or do you consider this too late?

The proposed API looks like this:
https://gist.github.com/morrisonlevi/5819a2b8d86561849ee916a7bcbc9c29.
Notably a `ReflectionClassType` will be returned if possible which has
a `getClass(): ReflectionClass` method. This has been a commonly
requested addition and simplifies a common use-case.

I tried to discuss these changes on Reddit to gauge community impact
but it had few responses:
https://www.reddit.com/r/PHP/comments/4m93s1/i_want_to_enhance_and_break_the_reflectiontype/.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

That's a bug ... that should throw ...

Cheers
Joe

On Fri, Jun 10, 2016 at 3:12 PM, Bob Weinand  wrote:

>
> Am 10.06.2016 um 16:00 schrieb Niklas Keller :
>
> 2016-06-10 15:50 GMT+02:00 Bob Weinand :
>
>>
>> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
>>
>>
>> Top-posting, since I'm taking off now.
>>
>> From outside the class, properties are not visible at all, so their types
>> are un-important from outer scopes.
>>
>> echo $foo->bar; is not the same in instance method body or outside of the
>> class.
>>
>> From outside it works just fine and doesn't throw:
>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties
>>
>>
>> This is an intermittent bug in the implementation.
>> the RFC is explicitly mentioning that it should throw and throwing also
>> is the correct behavior here.
>>
>
> I don't think this is and should be a bug. I think it is the right
> behavior if we choose to throw at all.
>
>
> In this case a definite -1 on the RFC from me. I don't want "surprises"
> regarding the type if a property is declared to return a certain type.
>
> Bob
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:24 schrieb Levi Morrison :
> 
> On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov  wrote:
>> Hi,
>> 
>> 
>> I hardly worked on implementation of this patch for a week, but I still 
>> don't like it.
>> 
>> It makes 15% slowdown on each property update in existing PHP code (without 
>> types), and I don't see a way to improve this.
>> 
>> Update of typed properties is going to be even more expensive.
>> 
>> Benchmark results are included into RFC (and not changed with the latest 
>> version of the patch).
>> 
>> 
>> -1.
>> 
>> 
>> Thanks. Dmitry.
>> 
>> 
>> From: Joe Watkins 
>> Sent: Friday, June 10, 2016 1:38:04 PM
>> To: PHP internals; Phil Sturgeon
>> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
>> 
>> Afternoon internals,
>> 
>>The vote for typed properties has been restarted.
>> 
>>Please take part: https://wiki.php.net/rfc/typed-properties
>> 
>> Cheers
>> Joe
> 
> To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
> slowdown? In my opinion that is definitely a tolerable performance hit
> for such a feature.

Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 
cache utilization and the number of executed instructions for a runtime-cached 
ASSIGN_OBJ is very small. Where even 4 additional instructions make significant 
difference.
The 0.1% slowdown of WP and MW are painting a much more realistic (aka 
real-world) image. And as the RFC writes, "may be caused not by the additional 
checks but by the worse CPU cache utilization, because the size of PHP code was 
increased on 40KB". 
These micro-benches are really insignificant, especially as it is trivial (in 
tight loops) to work on a local CV and only assign it later to the property.

This IMO is really voting no for the wrong reasons...

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Levi Morrison]

On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov  wrote:
> Hi,
>
>
> I hardly worked on implementation of this patch for a week, but I still don't 
> like it.
>
> It makes 15% slowdown on each property update in existing PHP code (without 
> types), and I don't see a way to improve this.
>
> Update of typed properties is going to be even more expensive.
>
> Benchmark results are included into RFC (and not changed with the latest 
> version of the patch).
>
>
> -1.
>
>
> Thanks. Dmitry.
>
> 
> From: Joe Watkins 
> Sent: Friday, June 10, 2016 1:38:04 PM
> To: PHP internals; Phil Sturgeon
> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
>
> Afternoon internals,
>
> The vote for typed properties has been restarted.
>
> Please take part: https://wiki.php.net/rfc/typed-properties
>
> Cheers
> Joe

To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
slowdown? In my opinion that is definitely a tolerable performance hit
for such a feature.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:16 schrieb Niklas Keller :
> 
> 
> 2016-06-10 16:12 GMT+02:00 Bob Weinand  >:
> In this case a definite -1 on the RFC from me. I don't want "surprises" 
> regarding the type if a property is declared to return a certain type.
> 
> Where's the surprise?

Receiving a different type than I asked for. (as promised by the type decl)

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

2016-06-10 16:12 GMT+02:00 Bob Weinand :

> In this case a definite -1 on the RFC from me. I don't want "surprises"
> regarding the type if a property is declared to return a certain type.
>

Where's the surprise?

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:00 schrieb Niklas Keller :
> 
> 2016-06-10 15:50 GMT+02:00 Bob Weinand  >:
> 
>> Am 10.6.2016 um 15:34 schrieb Niklas Keller > >:
>> 
>>> 
>>> Top-posting, since I'm taking off now.
>>> 
>>> From outside the class, properties are not visible at all, so their types
>>> are un-important from outer scopes.
>>> 
>>> echo $foo->bar; is not the same in instance method body or outside of the
>>> class.
>>> 
>> From outside it works just fine and doesn't throw:
>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties 
>> 
> 
> This is an intermittent bug in the implementation.
> the RFC is explicitly mentioning that it should throw and throwing also is 
> the correct behavior here.
> 
> I don't think this is and should be a bug. I think it is the right behavior 
> if we choose to throw at all. 

In this case a definite -1 on the RFC from me. I don't want "surprises" 
regarding the type if a property is declared to return a certain type.

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

2016-06-10 15:50 GMT+02:00 Bob Weinand :

>
> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
>
>
> Top-posting, since I'm taking off now.
>
> From outside the class, properties are not visible at all, so their types
> are un-important from outer scopes.
>
> echo $foo->bar; is not the same in instance method body or outside of the
> class.
>
> From outside it works just fine and doesn't throw:
> https://3v4l.org/L8CqF/rfc#rfc-typed_properties
>
>
> This is an intermittent bug in the implementation.
> the RFC is explicitly mentioning that it should throw and throwing also is
> the correct behavior here.
>

I don't think this is and should be a bug. I think it is the right behavior
if we choose to throw at all.

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
> 
>> 
>> Top-posting, since I'm taking off now.
>> 
>> From outside the class, properties are not visible at all, so their types
>> are un-important from outer scopes.
>> 
>> echo $foo->bar; is not the same in instance method body or outside of the
>> class.
>> 
> From outside it works just fine and doesn't throw:
> https://3v4l.org/L8CqF/rfc#rfc-typed_properties

This is an intermittent bug in the implementation.
the RFC is explicitly mentioning that it should throw and throwing also is the 
correct behavior here.

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

>
> Top-posting, since I'm taking off now.
>
> From outside the class, properties are not visible at all, so their types
> are un-important from outer scopes.
>
> echo $foo->bar; is not the same in instance method body or outside of the
> class.
>
>From outside it works just fine and doesn't throw:
https://3v4l.org/L8CqF/rfc#rfc-typed_properties

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Marco Pivetta]

Top-posting, since I'm taking off now.

>From outside the class, properties are not visible at all, so their types
are un-important from outer scopes.

echo $foo->bar; is not the same in instance method body or outside of the
class.
On Jun 10, 2016 2:55 PM, "Niklas Keller"  wrote:

> 2016-06-10 14:39 GMT+02:00 Marco Pivetta :
>
>> As already mentioned on twitter, I voted "no" on this RFC as it currently
>> stands. I might reconsider if following points are addressed:
>>
>>  1. __get semantics are not changed: let __get behave like it usually
>> does,
>> and let the user define a type hint on __get, should any be applicable.
>> Basically:
>>
>> class Foo
>> {
>> private int $bar = 123;
>> public function __get($name) { return 'banana'; } // *ALWAYS* works -
>> why would I even want a type error here?
>> }
>>
>
> You want a type error if bar is unset, mainly because Foo->bar should
> always be an int.
> If you unset it and set it again, it still has to be an int. And
> reflection will tell you it's always an int.
> So why should __get be allowed to return something different?
>
>
>>  * by-ref access should be enabled when the reference property has the
>> same
>> declared type as the source one
>>
>> class Foo
>> {
>> public int $bar = 123;
>> }
>>
>> class Bar
>> {
>> public int $baz = 456;
>> public string $taz = 'taz';
>> }
>>
>> $foo = new Foo;
>> $bar = new Bar;
>>
>> $bar->baz = & $foo->bar; // works
>> $bar->taz = & $foo->bar; // crashes
>>
>> Cheers,
>>
>>
>> Marco Pivetta
>>
>> http://twitter.com/Ocramius
>>
>> http://ocramius.github.com/
>>
>> On 10 June 2016 at 12:38, Joe Watkins  wrote:
>>
>> > Afternoon internals,
>> >
>> > The vote for typed properties has been restarted.
>> >
>> > Please take part: https://wiki.php.net/rfc/typed-properties
>> >
>> > Cheers
>> > Joe
>> >
>>
>
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Niklas Keller]

2016-06-10 14:39 GMT+02:00 Marco Pivetta :

> As already mentioned on twitter, I voted "no" on this RFC as it currently
> stands. I might reconsider if following points are addressed:
>
>  1. __get semantics are not changed: let __get behave like it usually does,
> and let the user define a type hint on __get, should any be applicable.
> Basically:
>
> class Foo
> {
> private int $bar = 123;
> public function __get($name) { return 'banana'; } // *ALWAYS* works -
> why would I even want a type error here?
> }
>

You want a type error if bar is unset, mainly because Foo->bar should
always be an int.
If you unset it and set it again, it still has to be an int. And reflection
will tell you it's always an int.
So why should __get be allowed to return something different?


>  * by-ref access should be enabled when the reference property has the same
> declared type as the source one
>
> class Foo
> {
> public int $bar = 123;
> }
>
> class Bar
> {
> public int $baz = 456;
> public string $taz = 'taz';
> }
>
> $foo = new Foo;
> $bar = new Bar;
>
> $bar->baz = & $foo->bar; // works
> $bar->taz = & $foo->bar; // crashes
>
> Cheers,
>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 10 June 2016 at 12:38, Joe Watkins  wrote:
>
> > Afternoon internals,
> >
> > The vote for typed properties has been restarted.
> >
> > Please take part: https://wiki.php.net/rfc/typed-properties
> >
> > Cheers
> > Joe
> >
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Marco Pivetta]

As already mentioned on twitter, I voted "no" on this RFC as it currently
stands. I might reconsider if following points are addressed:

 1. __get semantics are not changed: let __get behave like it usually does,
and let the user define a type hint on __get, should any be applicable.
Basically:

class Foo
{
private int $bar = 123;
public function __get($name) { return 'banana'; } // *ALWAYS* works -
why would I even want a type error here?
}

 * by-ref access should be enabled when the reference property has the same
declared type as the source one

class Foo
{
public int $bar = 123;
}

class Bar
{
public int $baz = 456;
public string $taz = 'taz';
}

$foo = new Foo;
$bar = new Bar;

$bar->baz = & $foo->bar; // works
$bar->taz = & $foo->bar; // crashes

Cheers,


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 10 June 2016 at 12:38, Joe Watkins  wrote:

> Afternoon internals,
>
> The vote for typed properties has been restarted.
>
> Please take part: https://wiki.php.net/rfc/typed-properties
>
> Cheers
> Joe
>

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Dmitry Stogov]

Hi,


I hardly worked on implementation of this patch for a week, but I still don't 
like it.

It makes 15% slowdown on each property update in existing PHP code (without 
types), and I don't see a way to improve this.

Update of typed properties is going to be even more expensive.

Benchmark results are included into RFC (and not changed with the latest 
version of the patch).


-1.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Friday, June 10, 2016 1:38:04 PM
To: PHP internals; Phil Sturgeon
Subject: [PHP-DEV] [RFC][Vote] Typed Properties

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

[PHP-DEV] [RFC][Vote] Typed Properties

[Joe Watkins]

Afternoon internals,

The vote for typed properties has been restarted.

Please take part: https://wiki.php.net/rfc/typed-properties

Cheers
Joe

Re: [PHP-DEV] Is this thing on?

[Rowan Collins]

On 09/06/2016 14:08, Lester Caine wrote:

Not seem any traffic for a couple of days?



It was definitely down for a while - I eventually got a bounce for one 
message - but seems to be back up now. I'm guessing a few 
out-of-sequence messages will find their way in, but anything sent 
between Monday afternoon and this morning (UTC) may have been discarded.


Now, back to business... ;)
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.0.8 RC1 is available for testing

[Anatol Belski]

Hi,

PHP 7.0.8 RC1 was just released and can be downloaded from:

https://downloads.php.net/~ab/

The Windows binaries are available at

http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your testing, please refer
to the NEWS file:

https://github.com/php/php-src/blob/php-7.0.8RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for June 23rd, if no critical issues will be
discovered in the RC.


Below is the verification information for the downloads:

php-7.0.8RC1.tar.bz2
SHA256 hash:
361602e5d21e43d1bd098402a832e63839e660de410eb4dac8291ef82f7989b5
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXVwl8AAoJELyqMOqcDVdjtUcH/2fUCRlBZ0jV0IoOMX1yOuQo
o/mfb+K6GrcWfvB2jMJpBIG75U7v6IfjXJxp5m4zsTG2HEHqvWSMt/UzqGUh9+eG
gFV9DMwU5zhHxI10GRtOsCpnuB+FGkmjywc1y5mNUyKIGKr6cse1lITrabY0wHag
SoIN/Te3XVYWTh6cPZvWfMYh10ZxzYGQDBbS+vkAjMK5UHzqilxNRKbKFYPs78g8
PBUNY7/1U4N2BtGaCcFctM9Vdy+yH7rl3gNnz+HJ7uWUSXVqv5wQnfgMQ1sd0KZ0
97JZjdqP2vnhqKY2KQBOz5wlIOk1OcEk+enRktbtL53/y4WmBnx2G3zpsOSWdAI=
=vAQV
-END PGP SIGNATURE-


php-7.0.8RC1.tar.gz
SHA256 hash:
f98a8092f02c616b246be8605e4ef03325c57e2c72e961d5f67d9f765b709822
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXVwl/AAoJELyqMOqcDVdjigkH/RhPfz7L4lp+4R5L3heQ2O1X
JUM4Eflkn/5X6Ac/1FFOQg3TVSfePpiCjRpmIF7cRzGfcxdvX3qtm4rNgPEfo0jX
VTEIxSC0rtOxWRMsIORksQspZRKmLpvD8MQVq5gUl9k6/XljuAGlJAmZ9n6rjN9q
jAS4DqF8iXjfS2+Hd4AHcvzhe/GvoJIPfFVcZx6/6NelroLQAYhpVPF4INaw0MQ5
Wy/2LNSkVrnyCHZs+HlCnr4uHpVUiohhUvON9KEe+pAcRKXA/vUdlkhF5qSBavgS
SMNecNrq2ItLmFEMdSu3Rey65f5bppA+KJlrfNA1JZf0+u9mDHvpQR+rniDzwls=
=UZai
-END PGP SIGNATURE-


php-7.0.8RC1.tar.xz
SHA256 hash:
f284927775283f1269020d618e757a564d586b37e0ef4e07ced202df577a15ba
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXVwmBAAoJELyqMOqcDVdjTecH/1v/7VKfZrkZtdjO6pTUiR4h
nb9sId+AFzVsywlRfygtS34E/wzhHLbIyC/nXay7kLJjtl7VgLAUGAjyTIIIrKZQ
Iu/c95mGiO97hqf4KAd9R2J1Vy6XvWc86AS7HnCTtLcjKZqQeUYjvK4g2Fs3G6gN
+QkVHjHvgqUIvP7tOgKvtRb4BCiLoFfNrHNTeRF7V+7ugGvHSWFpo+pp2n14Ey4R
/KjdDXHsFotRCJOyuWKRynUNWZYiCUKa/8y3QkgnW/i4pkiU42RiZC3To9JF0YfW
wtQQAXTGV9LFEIVNu6MFeoZIj3S8ZyEMgdz8ezjRVMl3fhrs1yKdlKS3ncuUDVg=
=76/a
-END PGP SIGNATURE-

Thank you for your support.

Anatol Belski and Ferenc Kovacs



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Test

[Sherif Ramadan]

Just testing that the mailing list is still working. Please ignore.

Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with"Too few arguments" exception

[Rowan Collins]

Apologies if this ends up as a duplicate. The list server seems to be, 
or have been, down, so trying to re-send and see what happens.



On 06/06/2016 14:38, Christoph Becker wrote:

In my opinion it would be good to more explicitly clarify what
constitutes an unacceptable BC break.  Bug fixes are allowed, but even
those sometimes cause a BC break (as a programmer may rely on the buggy
behavior).


Indeed, there is the famous xkcd cartoon highlighting that every change 
breaks somebody's expectations, and there is sometimes a grey area 
between clear bugs and unintended behaviour that is nonetheless unwise 
to change. There are also times when breaking compatibility is justified 
because the cost of doing so is low - e.g. the behaviour being changed 
is a rare edge case; or because the cost of *not* changing is high - 
e.g. fixing a major security flaw.


I think a case could be made for this change falling into the "cost of 
change is low" category, but am disappointed that the RFC itself makes 
no such case, and nor did there seem to be much engagement when it was 
raised on the pre-vote thread.


I'm also not convinced that such a justification would be in the spirit 
of the release process RFC. If the intent of the "no BC breaks in minor 
releases" policy is to make upgrades smoother, then producing fatal 
errors on code that previously ran without error seems like exactly what 
we should be avoiding.


I know that people SHOULD be fixing these incidences where they are 
producing Warnings currently, but that doesn't mean we can assume that 
they DO. This change has the same kind of implications as the removal of 
call-time pass-by-reference in 5.4, and I thought that was exactly what 
we didn't want to repeat.



Frankly, if this passes, as it currently looks set to do, I think the BC 
policy in the Release Process RFC should be officially abandoned or 
rewritten, because we will no longer be able to tell users "if it runs 
under 7.0, it will run under 7.1".


Regards,
--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-06-09

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-09 06:28:31+03:00
commit: 296aa36
previous commit:10f0562
revision date:  2016-06-08 18:37:32+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.22% -0.31%  0.76%  
  7.01%
:-|   Drupal 7.36 cgi -T1  0.14% -0.22%  4.50%  
  5.24%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.03%  0.76%  
  3.29%
:-|   bench.php cgi -T100  0.12% -0.76% 27.75%  
 -1.98%
:-(  micro_bench.php cgi -T10  0.01% -3.22%  2.53%  
  5.41%
:-|  mandelbrot.php cgi -T100  0.01%  0.35% 29.56%  
  6.91%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2016-06-09/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Is this thing on?

[Lester Caine]

Not seem any traffic for a couple of days?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [VOTE] Add curl_multi_errno(), curl_share_errno() and curl_share_strerror()

[Pierrick Charron]

Hi Internals,

Since I got no feedback on the RFC about the addition of those 3 functions
and that this is not a big change I decided to open the vote.

https://wiki.php.net/rfc/new-curl-error-functions

Feedback and questions are as always welcome !

[PHP-DEV] PHP 5.6.23 RC1 is available for testing

[Ferenc Kovacs]

Hello everyone,

PHP 5.6.23 RC1 was just released and can be downloaded from:

http://downloads.php.net/~tyrael/

The Windows binaries are available at http://windows.php.net/qa/

This release contains a number of bugfixes.
For the list of bugfixes that you can target in your
testing, please refer to the NEWS file:

https://github.com/php/php-src/blob/php-5.6.23RC1/NEWS

Please test it carefully, and report any bugs in the bug system.

The stable release is planned for Jun 23th, if no critical issues will
be discovered in the RC.

In case you think that other projects should also receive this kind
of emails, please let us know privately, and we will add them to the
list of projects to contact.

To verify the downloads, you can use the following information:

php-5.6.23RC1.tar.bz2
SHA256 hash:
e20ba10c07b4c3a9006e08e7e824e3c061416846e143a20f5cdb9b3a5e94e647
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXWnRAAAoJEMK/C8Qzz8izSvEH/2YBaqofMKBDZN+fZ97/72eH
mHg2qc5cEta/r1TcIXvEbEEjIzTjP8CXenvW6RTIsvapc8jZMN/085H50gqi8Wfl
vTOJc5wKaDT2lgfRrXBYtQUSXSem+7pFl5HAN4AyRVKOdCObdFhfYQg6RSX294Ih
iAopePLB+EBr8HPFUIJ2VexkWzEsguUfK77dGUqEL1DE0QzY8sK76kRqpNBW+sJl
q+9o8Q/3ZJLdEnV32GnRwqsVwjT1VqePpUhFVAKD9yXN202RF2tJYfhQnEArr8Bt
sEoM33YZ3N6X4cHV6F4LIKar4bLVsm5PktxQNC71NnFeb4lCEGhGHvcGioM0A4A=
=Nysc
-END PGP SIGNATURE-

php-5.6.23RC1.tar.gz
SHA256 hash:
b39f3cd2231bc206dec684f491647affaa0d04f844b3ec1d6a90c906e523
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXWnRIAAoJEMK/C8Qzz8izTsEH/jd+xma5FbSI3a46ZDp7dP5x
CQGOGXDQojpWtw60N/OUH3K4Sa0wEuxWTOSCa3oJPbGfE8UB7oSKDq+X6I+txGmL
1/32rNe//IrRbos/z7jTAD5qmWYItfKrxZHknHwZW4NX/V/J4YCIg2uCahl4imYe
WoynocBuQ+gYWDUnnsq+t65sw+NA9p7uXfATifCNHiqdqAZOcQPuvpfcq6ErKu+V
foiD/AdrhMYyiAYg0122Xa4iicVwBg0Vw38mL/gdnAT5YeGbhuz1cLVv5sh3mGHX
HFcmGx92GimgBHdiQkXsyJ2IzkBOZicyd95LZTF3PRf5MNC9ojtDV8BlahwsM6w=
=pzjL
-END PGP SIGNATURE-

php-5.6.23RC1.tar.xz
SHA256 hash:
235e66d347e67efbbad1fcdc82e754e13b1deb94a85a38b2bf2a2275b5d6f01d
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAABAgAGBQJXWnROAAoJEMK/C8Qzz8iz1s0IAJNHcVFmVQaXQK6K+Fd4L5iT
qAF5RLfXxNHgnfAHwT+8KLr/cUcixdpsmFh31baFJeqRCSYHFV20+57jf7eOZFLM
5MBs8U86Pfkpyuw7U28fDuyfeuOSqd8ZilMoRUCFIRpTCtQ+e1DYGXdYzS6ckIkz
vT4UqenYL6Wj++03qaL4a68RkkcNB/fep5Lqy5rIrU7s6cg+Zii9dJvg/Iw5tiX+
KkafYB2R9ZRQnZgitGeu/65yHfbHJ66DiGdoQkn7E7obkXubH2zhJKxDTj5M8313
xwm6dNleKC8+WG2JG4W+XER6vGpMcWdwjRFUNkki7qKrQzpJ1nJNtEh9o7eSk9s=
=7nZy
-END PGP SIGNATURE-

Thank you for your support.

Ferenc Kovacs & Julien Pauli