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

Everything fine now. From: Pierre Joye Sent: Tuesday, June 28, 2016 5:39:08 AM To: Dmitry Stogov Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead). hi, On Fri, Jun 24, 2016 at 5:20 PM, Dmitry

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

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

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

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 >

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

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 >

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

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 I

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

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

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

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 on

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

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 =

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

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

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

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 allow

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

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

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

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

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

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 li

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

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 loo

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

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 http

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

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/ph

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

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 i

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

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

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

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

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

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

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

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

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

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 Eng

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

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

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

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 se

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

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

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

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.