Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Pierre Joye]

hi,

On Fri, Jun 24, 2016 at 5:20 PM, Dmitry Stogov  wrote:
> Hi internals,
>
>
> Please review the RFC https://wiki.php.net/rfc/async_signals

Travis is not happy in ZTS, can you check please?

https://travis-ci.org/php/php-src/jobs/139981256

-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Pierre Joye]

hi,

On Mon, Jun 27, 2016 at 10:17 PM, Aaron Piotrowski  wrote:
> Hello,
>
> Voting has opened on the RFC to change most conditions in extensions that 
> raise E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead.
>
> RFC: https://wiki.php.net/rfc/throw_error_in_extensions 
> 
> PR: https://github.com/php/php-src/pull/1942 
> 

I like the idea.

It should be 2/3 tho'.

Also "Generally none, though it is possible some exceptions thrown
could be unintentionally caught by code written for PHP 7. However, it
is rare for Errorexceptions to be caught outside of cleanup or
logging, so catching these exceptions is likely desirable over a fatal
error." is a BC break, not sure there are codes out there that expects
or may behave (more) badly with this than with a fatal error.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC DISCUSSION] var_info

[Jesse Schalken]

On Mon, Jun 27, 2016 at 3:19 AM, Fleshgrinder  wrote:

> I would like to start the discussion on the already announced var_info()
> function. Especially the following open issues should be addressed
> before going into voting:
>
> 1. Whether to output "negative zero float" for -0.0 or keep "zero
> float". This functionality was requested on Reddit but IEEE 754 actually
> says that one should ignore the difference. Detecting the negative zero
> would also require the signbit functionality from C99 (or weird hacking).
>

I think IEEE 754 only specifies that -0.0 and +0.0 be considered equal for
the purpose of numeric equality. That doesn't necessarily mean converting
to a string in some manner should produce the same result. It is already
the case that (string)(float)-0.0 === "-0" and this is how I check for -0.0
in PHP.


> 2. Whether to output "invalid object" instead of "object of class
> __PHP_Incomplete_Class" to make it more clear cut that this object is
> wonky.
>
> https://wiki.php.net/rfc/var_info
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

Re: [PHP-DEV] [RFC DISCUSSION] var_info

[Dan Ackroyd]

On 26 June 2016 at 18:19, Fleshgrinder  wrote:
> I would like to start the discussion on the already announced var_info()
> function.
>
> https://wiki.php.net/rfc/var_info

The RFC doesn't seem to state any reason why this should be in core,
rather than in a userland library.

cheers
Dan

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

Re: [PHP-DEV] [RFC DISCUSSION] Error Storage Behavior

[Stanislav Malyshev]

Hi!

> Currently error_get_last() always contains the last error that occurred,
> however, this is actually not desired if the last error was an exception
> that was caught.
> 
> https://github.com/php/php-src/pull/1936

I think conditioning warnings on whether exception is caught or not is a
very bad idea. However, having _either_ exception _or_ PHP error and not
producing both (except in the case where uncaught exception becomes
fatal error I guess) may be a good idea, but it needs careful checking
of the implications. In general, old error mechanism and exceptions are
not very good combination, and using them together may be troublesome.

It's definitely not "just a bug fix" - it needs careful check of what
exactly happens when.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Simple Annotations

[Rasmus Schultz]

Tonight I started trying to write a proposal for even more simplified
annotations, e.g. something simple enough that it cannot result in
fatal errors. I eventually gave up, and here's why.

Essentially, if you have to restrict yourself to things that cannot
under any circumstances error out, the only things you can use are
constant scalar values - even constant scalar expressions could not be
allowed, because even those could error when CONST_NAME or
Class::CONST_NAME aren't defined.

So, in a nutshell, what you're saying (Richard) is that annotations
can only consist of scalar values, and possibly arrays of values? (and
I don't even see your gist doing that - it's just invoking closures,
as far as I can tell, and any of those could error, or not?)

So, regardless of syntax, literally the only annotation data allowed
would be blatantly simple things like:

["max_length" => 20]

["data_type" => "int"]

Or in other words, constant arrays, int, string, float and bool
values. Nothing else.

Nothing can depend on any kind of external symbol (class names,
constants, etc.) since any such reference can cause an error.

No static analysis or type-checking of any kind can ever be performed
- no assertions or declarations can be made about the shape or types
of metadata, at all.

The problem is, that's simply not useful.

It's also not very different from what we have today with php-doc
blocks - the only real difference is we can check array nesting and
int, string, float and bool syntax, e.g. nothing really useful or
important.

In other words, this would be a very slight improvement on syntax -
nothing that actually amounts to any kind of functionality.

If we were to ship a feature like that, what would happen is precisely
the same thing that happened with php-doc blocks: the real work will
be done in userland (and likely dominated by one library), there will
be no IDE support (except proprietary support for that one dominating
library), no useful offline static analysis tools.

At the end of the day, what we end up with will have all of the same
issues we have with php-doc blocks and existing libraries.

I don't understand how such a feature would be useful to anybody?

I especially don't understand why you want a language feature that
isn't allowed to reference external symbols - e.g. isn't allowed to
have any kind of relationship with anything declared in userland.

It seems to me a peculiar, arbitrary and unrealistic restriction to
put on annotations.

It's going to have no immediate usefulness, and mapping the data to
objects is going to happen in userland, just as it does today.

I'd like to work on this proposal, but I feel that you're giving me
nothing to work with here.


On Mon, May 16, 2016 at 12:38 PM, Fleshgrinder  wrote:
> On 5/13/2016 2:11 PM, Rasmus Schultz wrote:
>> Dear Internals,
>>
>> I'm announcing a simplified RFC for annotations:
>>
>> https://wiki.php.net/rfc/simple-annotations
>>
>
> -1 again, I am sorry.
>
> The problem is that an annotation by definition is just meta-data. Your
> proposal however might result in fatal errors from meta-data:
>
>   $reflector = new ReflectionClass(User::class);
>   $reflector->getAnnotations();
>
>   // Fatal error: Uncaught Error: Class 'TableName' not found ...
>
> This is an absolute No-Go for meta-data.
>
> --
> Richard "Fleshgrinder" Fussenegger
>

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

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Karl Pflästerer]

Bishop Bettini  writes:

> On Mon, Jun 27, 2016 at 11:31 AM, Andreas Heigl  wrote:
>
>> Am 27.06.16 um 15:28 schrieb Karl Pflästerer:
>> > Andreas Heigl  writes:
>> >
>> >> Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
>> >>> interface I1 { const C1 = '';}
>> >>> class C3 implements I1 { const C1 = 'c2';}
>> >>> $c3 = new C3;
>> >>> var_dump($c3::C1);
>> >>
>> >> According to https://3v4l.org/jIcs6 it looks like that's intended
>> >> behaviour ;)
>> >
>> > But why does it work in the CLI if I write the code (instead of using a
>> > script)?  That's my question.
>>
>> It doesn't. At least not on my machine. This is the output I get:
>>
>> $ php -v
>> PHP 7.1.0alpha2 (cli) (built: Jun 24 2016 13:50:28) ( NTS )
>> Copyright (c) 1997-2016 The PHP Group
>> Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
>>
>
> Technically, this is a different version than reported. Nonetheless, on the
> same version my REPL complains as well, I suspect because the original
> report misspelled the INI setting ("-ddispplay_errors=On", notice the
> double "p"):

[...]

Thanks; that explains why I didn't see the error message.

>
> Under normal interpretive operation, the Fatal terminates the script. But
> in the case of the REPL command line, those are swallowed up and you can
> keep going. Same as like:
>


And that explains why I was able to instantiate a broken class (with a
overriden constant).

So no bug but an interesting edge case.

  KP


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

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Bishop Bettini]

On Mon, Jun 27, 2016 at 11:44 AM, Rowan Collins 
wrote:

>
> PHP Fatal error:  Cannot inherit previously-inherited or override
>> constant C1 from interface I1 in
>>
>
> Can I just say this is a positively hideous error message. I can't
> actually figure out how to parse its grammar: is it (inherit
> previously-inherited) OR (override)? If so, what does "inherit
> previously-inherited" mean?
>
>
+1 on hideous.

>From this test
, I
believe "previously-inherited" refers to this situation:

interface I1 { const BAR = 242; }
interface I2 { const BAR = 242; }
class Foo implements I1, I2 { };

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Rowan Collins]

On 27/06/2016 16:31, Andreas Heigl wrote:

So it crashes with a fatal error when Implementing the interface. It'S
interesting though that the script allows me to instantiate the class
nonetheless.


It sounds to me like the ability of the interactive shell to catch fatal 
errors and continue allows you to execute code with the engine in a 
bogus state.


It's possible to do all sorts of wacky things that way:

php > class Bogus implements NonExistent {}
PHP Fatal error:  Interface 'NonExistent' not found in php shell code on 
line 1


Fatal error: Interface 'NonExistent' not found in php shell code on line 1
php > $b = new Bogus;
php > var_dump($b);
object(Bogus)#1 (0) {
}
php > var_dump($b instanceOf NonExistent);
bool(false)
php > var_dump($b instanceOf Bogus);
bool(true)




PHP Fatal error:  Cannot inherit previously-inherited or override
constant C1 from interface I1 in


Can I just say this is a positively hideous error message. I can't 
actually figure out how to parse its grammar: is it (inherit 
previously-inherited) OR (override)? If so, what does "inherit 
previously-inherited" mean?


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

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Andreas Heigl]

Am 27.06.16 um 17:41 schrieb Bishop Bettini:
> On Mon, Jun 27, 2016 at 11:31 AM, Andreas Heigl  wrote:
> 
>> Am 27.06.16 um 15:28 schrieb Karl Pflästerer:
>>> Andreas Heigl  writes:
>>>
 Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
> interface I1 { const C1 = '';}
> class C3 implements I1 { const C1 = 'c2';}
> $c3 = new C3;
> var_dump($c3::C1);

 According to https://3v4l.org/jIcs6 it looks like that's intended
 behaviour ;)
>>>
>>> But why does it work in the CLI if I write the code (instead of using a
>>> script)?  That's my question.
>>
>> It doesn't. At least not on my machine. This is the output I get:
>>
>> $ php -v
>> PHP 7.1.0alpha2 (cli) (built: Jun 24 2016 13:50:28) ( NTS )
>> Copyright (c) 1997-2016 The PHP Group
>> Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
>>
> 
> Technically, this is a different version than reported. Nonetheless, on the
> same version my REPL complains as well, I suspect because the original
> report misspelled the INI setting ("-ddispplay_errors=On", notice the
> double "p"):
> 
> $ php -v
> PHP 7.0.7 (cli) (built: May 28 2016 08:26:36) ( NTS )
> Copyright (c) 1997-2016 The PHP Group
> Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
> Technologies
> with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans
> 
> $ php -a
> Interactive shell
> 
> php > interface I1 { const C1 = ''; }
> php > class C3 implements I1 { const C1 = 'c2'; }
> PHP Fatal error:  Cannot inherit previously-inherited or override constant
> C1 from interface I1 in php shell code on line 1
> PHP Stack trace:
> PHP   1. {main}() php shell code:0
> 
> 
> 
>> So it crashes with a fatal error when Implementing the interface. It'S
>> interesting though that the script allows me to instantiate the class
>> nonetheless. That's right.
>>
> 
> Under normal interpretive operation, the Fatal terminates the script. But
> in the case of the REPL command line, those are swallowed up and you can
> keep going. Same as like:
> 
> php > foo();
> PHP Warning:  Uncaught Error: Call to undefined function foo() in php shell
> code:1
> Stack trace:
> #0 {main}
>   thrown in php shell code on line 1
> PHP Stack trace:
> PHP   1. {main}() php shell code:0
> php > echo 'hi';
> hi
> 
> I'm not seeing any bugs here.

Thanks for the info.

What I find strange is that I can instantiate the class "C3" even though
the declaration of the class is broken. I wouldn't say it's a bug, but
interesting.

Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Bishop Bettini]

On Mon, Jun 27, 2016 at 11:31 AM, Andreas Heigl  wrote:

> Am 27.06.16 um 15:28 schrieb Karl Pflästerer:
> > Andreas Heigl  writes:
> >
> >> Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
> >>> interface I1 { const C1 = '';}
> >>> class C3 implements I1 { const C1 = 'c2';}
> >>> $c3 = new C3;
> >>> var_dump($c3::C1);
> >>
> >> According to https://3v4l.org/jIcs6 it looks like that's intended
> >> behaviour ;)
> >
> > But why does it work in the CLI if I write the code (instead of using a
> > script)?  That's my question.
>
> It doesn't. At least not on my machine. This is the output I get:
>
> $ php -v
> PHP 7.1.0alpha2 (cli) (built: Jun 24 2016 13:50:28) ( NTS )
> Copyright (c) 1997-2016 The PHP Group
> Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
>

Technically, this is a different version than reported. Nonetheless, on the
same version my REPL complains as well, I suspect because the original
report misspelled the INI setting ("-ddispplay_errors=On", notice the
double "p"):

$ php -v
PHP 7.0.7 (cli) (built: May 28 2016 08:26:36) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
Technologies
with Xdebug v2.4.0, Copyright (c) 2002-2016, by Derick Rethans

$ php -a
Interactive shell

php > interface I1 { const C1 = ''; }
php > class C3 implements I1 { const C1 = 'c2'; }
PHP Fatal error:  Cannot inherit previously-inherited or override constant
C1 from interface I1 in php shell code on line 1
PHP Stack trace:
PHP   1. {main}() php shell code:0



> So it crashes with a fatal error when Implementing the interface. It'S
> interesting though that the script allows me to instantiate the class
> nonetheless. That's right.
>

Under normal interpretive operation, the Fatal terminates the script. But
in the case of the REPL command line, those are swallowed up and you can
keep going. Same as like:

php > foo();
PHP Warning:  Uncaught Error: Call to undefined function foo() in php shell
code:1
Stack trace:
#0 {main}
  thrown in php shell code on line 1
PHP Stack trace:
PHP   1. {main}() php shell code:0
php > echo 'hi';
hi

I'm not seeing any bugs here.

bishop

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Andreas Heigl]

Am 27.06.16 um 15:28 schrieb Karl Pflästerer:
> Andreas Heigl  writes:
> 
>> Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
>>> interface I1 { const C1 = '';}
>>> class C3 implements I1 { const C1 = 'c2';}
>>> $c3 = new C3;
>>> var_dump($c3::C1);
>>
>> According to https://3v4l.org/jIcs6 it looks like that's intended
>> behaviour ;)
> 
> But why does it work in the CLI if I write the code (instead of using a
> script)?  That's my question.

It doesn't. At least not on my machine. This is the output I get:

$ php -v
PHP 7.1.0alpha2 (cli) (built: Jun 24 2016 13:50:28) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies

$ php -a
Interactive shell

php > interface I1 { const C1 = '';}
php > class C3 implements I1 { const C1 = 'c2';}
PHP Fatal error:  Cannot inherit previously-inherited or override
constant C1 from interface I1 in php shell code on line 1

Fatal error: Cannot inherit previously-inherited or override
constant C1 from interface I1 in php shell code on line 1
php > $c3 = new C3;
php > var_dump($c3::C1);
string(2) "c2"
php >

So it crashes with a fatal error when Implementing the interface. It'S
interesting though that the script allows me to instantiate the class
nonetheless. That's right.

Perhaps some C-Guru can shed some light here?

Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Christoph Becker]

On 27.06.2016 at 15:28, (Karl Pflästerer ) wrote:

> Andreas Heigl  writes:
> 
>> Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
>>> interface I1 { const C1 = '';}
>>> class C3 implements I1 { const C1 = 'c2';}
>>> $c3 = new C3;
>>> var_dump($c3::C1);
>>
>> According to https://3v4l.org/jIcs6 it looks like that's intended
>> behaviour ;)
> 
> But why does it work in the CLI if I write the code (instead of using a
> script)?  That's my question.

Have you tried with and without OPcache?

-- 
Christoph M. Becker


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

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Karl Pflästerer]

Am 27.06.16 um 17:04 schrieb Christoph Becker:

On 27.06.2016 at 15:28, (Karl Pflästerer ) wrote:


Andreas Heigl  writes:


Am 27.06.16 um 15:01 schrieb Karl Pflästerer:

interface I1 { const C1 = '';}
class C3 implements I1 { const C1 = 'c2';}
$c3 = new C3;
var_dump($c3::C1);


According to https://3v4l.org/jIcs6 it looks like that's intended
behaviour ;)


But why does it work in the CLI if I write the code (instead of using a
script)?  That's my question.


Have you tried with and without OPcache?



There is no opcache in use. (Don't know if the message can be seen on 
the list; I only could read it in my mailbox; I could'nt see it in Gmane).


  KP

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

[PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Aaron Piotrowski]

Hello,

Voting has opened on the RFC to change most conditions in extensions that raise 
E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead.

RFC: https://wiki.php.net/rfc/throw_error_in_extensions 

PR: https://github.com/php/php-src/pull/1942 


Aaron Piotrowski

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Karl Pflästerer]

Andreas Heigl  writes:

> Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
>> interface I1 { const C1 = '';}
>> class C3 implements I1 { const C1 = 'c2';}
>> $c3 = new C3;
>> var_dump($c3::C1);
>
> According to https://3v4l.org/jIcs6 it looks like that's intended
> behaviour ;)

But why does it work in the CLI if I write the code (instead of using a
script)?  That's my question.

  KP


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

Re: [PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Andreas Heigl]

Am 27.06.16 um 15:01 schrieb Karl Pflästerer:
> interface I1 { const C1 = '';}
> class C3 implements I1 { const C1 = 'c2';}
> $c3 = new C3;
> var_dump($c3::C1);

According to https://3v4l.org/jIcs6 it looks like that's intended
behaviour ;)

Cheers

Andreas

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



smime.p7s
Description: S/MIME Cryptographic Signature

[PHP-DEV] Possible Bug with Interface, Constants and Inheritance

[Karl Pflästerer]

Hi,
I'm not sure if it's a bug or not.

Consider these simple script:

 php -v
PHP 7.0.7 (cli) (built: May 27 2016 15:22:32) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
~> php -a -ddispplay_errors=On
Interactive shell

php > interface I1 { const C1 = '';}
php > class C3 implements I1 { const C1 = 'c2';}
php > $c3 = new C3;
php > var_dump($c3::C1);
string(2) "c2"


Is this always the correkt behaviour?

  KP


-- 
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-27

[lp_benchmark_robot]

Results for project PHP master, build date 2016-06-27 06:29:51+03:00
commit: e539823
previous commit:c9a538c
revision date:  2016-06-26 13:36:44-04: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.10% -0.05%  0.44%  
  7.81%
:-|   Drupal 7.36 cgi -T1  0.17% -0.11% -0.69%  
  5.49%
:-|   MediaWiki 1.23.9 cgi -T5000  0.09% -0.35%  1.05%  
  4.35%
:-|   bench.php cgi -T100  0.00%  0.24% 27.57%  
 -1.31%
:-(  micro_bench.php cgi -T10  0.01% -1.52%  4.00%  
  3.75%
:-(  mandelbrot.php cgi -T100  0.01% -1.60% 30.02%  
  6.00%
---

* 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-27/

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

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Joe Watkins]

Pierre,

> It affects how signals are handled within the engine, obvioulsy.

How signals are handled in the engine was already changed, the only
thing being proposed here is that ext/pcntl uses that new feature.

Cheers
Joe

On Mon, Jun 27, 2016 at 12:28 PM, Dmitry Stogov  wrote:

>
>
> On 06/27/2016 02:05 PM, Pierre Joye wrote:
>
>> On Mon, Jun 27, 2016 at 5:08 PM, Joe Watkins 
>> wrote:
>>
>>> Morning,
>>>
>>>  How is the impact wider than ext/pcntl ?
>>>
>> The implementation is only in pctnl. The feature is used indirectly by
>> the engine and makes it a core feature. Quote from the RFC:
>>
>> "Zend Engine in PHP 7.1 was extended with ability of safe time-out and
>> interrupt handling. Actually, PHP VM checks for EG(vm_interrupt) flag
>> on each loop iteration, user function entry or internal function exit,
>> and call callback function if necessary.
>>
>> I propose to use this ability to implement asynchronous signal
>> handling. Registered signal handlers are going to be called at some
>> points during user script execution without any overhead."
>>
>> and the test:
>>
>> > ini_set("pcntl.async_signals", "1");
>> pcntl_signal(SIGTERM, function ($signo) { echo "Signal handler
>> called!\n"; });
>>
>> echo "Start!\n";
>> posix_kill(posix_getpid(), SIGTERM);
>> $i = 0; // dummy
>> echo "Done!\n";
>>
>> It affects how signals are handled within the engine, obvioulsy.
>>
>> I have no doubt that this RFC will be accepted, by large, so it is not
>> a big issue. However it does affect the engine so the 2/3 rule
>> applies.
>>
> We use 2/3 vote for "a feature affecting the language itself (new syntax
> for example)", not the engine internals.
>
> https://wiki.php.net/RFC/voting#voting
>
>

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Dmitry Stogov]

On 06/27/2016 02:05 PM, Pierre Joye wrote:

On Mon, Jun 27, 2016 at 5:08 PM, Joe Watkins  wrote:

Morning,

 How is the impact wider than ext/pcntl ?

The implementation is only in pctnl. The feature is used indirectly by
the engine and makes it a core feature. Quote from the RFC:

"Zend Engine in PHP 7.1 was extended with ability of safe time-out and
interrupt handling. Actually, PHP VM checks for EG(vm_interrupt) flag
on each loop iteration, user function entry or internal function exit,
and call callback function if necessary.

I propose to use this ability to implement asynchronous signal
handling. Registered signal handlers are going to be called at some
points during user script execution without any overhead."

and the test:

We use 2/3 vote for "a feature affecting the language itself (new syntax 
for example)", not the engine internals.


https://wiki.php.net/RFC/voting#voting


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

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Pierre Joye]

On Mon, Jun 27, 2016 at 5:08 PM, Joe Watkins  wrote:
> Morning,
>
> How is the impact wider than ext/pcntl ?

The implementation is only in pctnl. The feature is used indirectly by
the engine and makes it a core feature. Quote from the RFC:

"Zend Engine in PHP 7.1 was extended with ability of safe time-out and
interrupt handling. Actually, PHP VM checks for EG(vm_interrupt) flag
on each loop iteration, user function entry or internal function exit,
and call callback function if necessary.

I propose to use this ability to implement asynchronous signal
handling. Registered signal handlers are going to be called at some
points during user script execution without any overhead."

and the test:

http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Joe Watkins]

Morning,

How is the impact wider than ext/pcntl ?

Cheers
Joe

On Mon, Jun 27, 2016 at 7:49 AM, Pierre Joye  wrote:

>
> On Jun 27, 2016 1:20 PM, "Joe Watkins"  wrote:
>
> > The proposed version of this RFC is 7.1, and the discussion was
> started
> > very late. However, since this is a self contained change in an
> extension,
> > I'm not sure it needs a 2/3 majority, and I'm not sure that it needs a
> full
> > discussion/voting period.
>
> Well, the code yes not the impact.
>

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

[Joe Watkins]

Morning,

   Voting closed, feature declined ...

Cheers
Joe

On Mon, Jun 27, 2016 at 10:12 AM, Christoph Becker 
wrote:

> On 10.06.2016 at 12:38, Joe Watkins wrote:
>
> > The vote for typed properties has been restarted.
> >
> > Please take part: https://wiki.php.net/rfc/typed-properties
>
> I've noticed that the vote for this RFC is still open, even though it
> states:
>
> | Voting started 10th June, ends 24th June 2016.
>
> --
> Christoph M. Becker
>
>

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

[Christoph Becker]

On 10.06.2016 at 12:38, Joe Watkins wrote:

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

I've noticed that the vote for this RFC is still open, even though it
states:

| Voting started 10th June, ends 24th June 2016.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Dmitry Stogov]

I don't know what is broken


From: Sebastian Bergmann 
Sent: Sunday, June 26, 2016 8:27:12 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and 
any additional overhead).

Am 24.06.2016 um 12:20 schrieb Dmitry Stogov:
> Please review the RFC https://wiki.php.net/rfc/async_signals

Would this alleviate the fact that ticks are broken in PHP 7? See
https://github.com/sebastianbergmann/phpunit/issues/2205 for what I use
ticks for in PHPUnit.

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

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Pierre Joye]

On Jun 27, 2016 1:20 PM, "Joe Watkins"  wrote:

> The proposed version of this RFC is 7.1, and the discussion was
started
> very late. However, since this is a self contained change in an extension,
> I'm not sure it needs a 2/3 majority, and I'm not sure that it needs a
full
> discussion/voting period.

Well, the code yes not the impact.

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Joe Watkins]

Morning internals,

The proposed version of this RFC is 7.1, and the discussion was started
very late. However, since this is a self contained change in an extension,
I'm not sure it needs a 2/3 majority, and I'm not sure that it needs a full
discussion/voting period.

So I'm happy for this to go into 7.1, if we can resolve the outstanding
question of configuration before voting commences, or as part of the vote.

The introduction of new ini entries is something we try to avoid, and
would be the only reason you could argue this requires a super majority
(although I think that argument invalid).

I think I prefer bob's idea to have a flag parameter on pcntl_signal:

  * it avoids a new ini entry, and additional functions
  * it gives a more granular control over execution

I'd like to see the implementation updated to use this approach and a
simple 50%+1 Yes/No vote, alternatively, include this as a voting option.

The vote needs to be opened by June 29th for a one week (minimum)
voting period.

Cheers
Joe

On Sun, Jun 26, 2016 at 3:14 PM, Bob Weinand  wrote:

>
> > Am 24.06.2016 um 12:20 schrieb Dmitry Stogov :
> >
> > Hi internals,
> >
> >
> > Please review the RFC https://wiki.php.net/rfc/async_signals
> >
> >
> > Thanks. Dmitry.
>
> Overall, I really like the approach.
>
> I've thought a bit about the function vs. ini approach.
>
> Advantage INI:
> - Global setting, set it once, works everywhere
>
> Advantage function:
> - You are guaranteed one specific initial value and don't see surprises
> when one environment doesn't match your default and you forgot to
> explicitly enable/disable it.
>
> The former one is good when you have your own scripts everywhere on the
> server, the latter is preferable when you are installing external
> applications.
>
> An alternative approach would be adding a flag to pcntl_signal() whether
> it should be dispatched asynchronously or held back for synchronous
> dispatching (with async being the default).
>
> I prefer that third option because of the following scenario:
> a phpunit test with timeout testing an event loop. Event loops naturally
> want to enable synchronous dispatching, which obviously will hold back the
> signal and thus the alarm set up by phpunit will never be triggered if the
> test ends up in e.g. an infinite loop.
>
> I'm not convinced by this solution, but it's the best one I can think of
> solving all the cases.
>
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>