Re: [PHP-DEV] How to indicate support for unimplemented part of an RFC

On 14/06/2016 20:11, Leigh wrote: On Mon, 13 Jun 2016 at 22:30 Matthew Browne wrote: Hi, What is the proper way to express support for an item that's not an official part of an RFC but is listed as an idea for future consideration? Specifically I wanted to give my "+1" for covariant return typ

[PHP-DEV] Throwing an Error for require expressions in PHP7.x

Hi, internals! For PHP7 we have pretty errors for almost everything, even eval can throw a ParseError exception, but not for the require expression, because it's still producing an uncatchable fatal errors: try { require('no.php'); } catch (Throwable $e) { echo 'Catch!'; } finally { e

Re: [PHP-DEV] [RFC] RNG fixes

On Tue, Jun 14, 2016 at 11:46 PM, Leigh wrote: > Hey Internals, > > I realise I'm cutting it close with this one, but I want to propose some > changes to our standard random number generators. > > The downside of this proposal is that our RNGs (rand() and mt_rand()) are > seedable and reproduce id

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

On 15/06/2016 11:27, Alexander Lisachenko wrote: For PHP7 we have pretty errors for almost everything, even eval can throw a ParseError exception, but not for the require expression Agree that this would be good. I don't know if there's a technical reason against it, or just that nobody's got

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

On Tue, Jun 14, 2016 at 11:17 PM, Fleshgrinder wrote: > On 6/14/2016 12:43 PM, Dmitry Stogov wrote: >> Hi, >> >> Just take into account, that 7.0 was released more than after 10 >> years of php-5 life, and of course we don't have any plans or goal >> for 8.0 yet. >> >> Waiting another 10 years for

[PHP-DEV] Re: Throwing an Error for require expressions in PHP7.x

On 15.06.2016 at 12:27, Alexander Lisachenko wrote: > For PHP7 we have pretty errors for almost everything, even eval can throw a > ParseError exception, but not for the require expression, because it's > still producing an uncatchable fatal errors: > > try { > require('no.php'); > } catch (T

Re: [PHP-DEV] [RFC] RNG fixes

On 14.06.2016 at 21:12, Fleshgrinder wrote: > On 6/14/2016 8:56 PM, Christoph Becker wrote: > >> Yes, I'm aware of that, and that change isn't an issue for me (except >> maybe that it might happen in a minor version). I was responding to >> Richard (Fleshgrinder) who suggested to remove rand() an

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

Results for project PHP master, build date 2016-06-15 06:30:06+03:00 commit: 3389c2e previous commit:14e790a revision date: 2016-06-14 22:39:18+02:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] Re: [RFC] RNG fixes

On 15.06.2016 at 01:08, Tom Worster wrote: > On 6/14/16 12:46 PM, Leigh wrote: > >> The RFC can be found here: https://wiki.php.net/rfc/rng_fixes > > Thanks for putting this together. I am strongly pro on two points and > moderately contra on the other two. I'd prefer separated votes, even > tho

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

On 15/06/2016 11:41, Pierre Joye wrote: I also understand the needs to change, update, optimize or clean our edge cases to open the path to JIT and the likes. However I would be very careful about that, and Dmitry and the team are very careful. I also have to say that to the very short timeline t

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/16 6:33 AM, Pierre Joye wrote: > * Alternatively, fixing the current mt_rand() implementation to make it > standard That sounds more reasonable. An option (please no ini as it is a programatic flow feature, not a php configuration problem) to keep the old behavior for BC. Having to add a

[PHP-DEV] PHP allocating too much memory

Hi - I'm getting the following error in php7.0.5: Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 140729445144864 bytes) If it's relevant, we're using dblib+freetds. I can't reproduce the issue deterministically; the best I can do is to repeatedly curl an endpoi

Re: [PHP-DEV] [RFC] RNG fixes

On 15/06/2016 13:41, Tom Worster wrote: int mt_rand ( $mode = MT_RAND_COMPAT ) int mt_rand ( int $min, int $max, $mode = MT_RAND_COMPAT ) MT_RAND_COMPAT = 1 MT_RAND_MT19937 = 2 A PHP user needs to make the right choice of what to use in their situation. A technical description

Re: [PHP-DEV] PHP allocating too much memory

On 15/06/2016 14:01, Peter LeBrun wrote: Hi - I'm getting the following error in php7.0.5: Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 140729445144864 bytes) If it's relevant, we're using dblib+freetds. I can't reproduce the issue deterministically; the be

Re: [PHP-DEV] [RFC] [VOTE] Union types

On 15.06.2016 at 00:51, Levi Morrison wrote: > On Tue, Jun 14, 2016 at 2:43 PM, Zeev Suraski wrote: >> >> On 14 ביוני 2016, at 22:53, Levi Morrison wrote: >> >> I'm personally against Union types because it makes no sense for classes >> >> I've been over this before but I'll repeat it here for c

Re: [PHP-DEV] PHP allocating too much memory

Hi, On Wed, 2016-06-15 at 09:01 -0400, Peter LeBrun wrote: > I'm getting the following error in php7.0.5: > > Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to > allocate 140729445144864 bytes) The huge number 140729445144864 is most likely consequence of an overflow. Can

RE: [PHP-DEV] [RFC] [VOTE] Union types

> -Original Message- > From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf > Of Levi Morrison > Sent: Wednesday, June 15, 2016 1:51 AM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] [VOTE] Union types > > On Tue, Jun 14, 2016 at 2:43 PM, Zeev

Re: [PHP-DEV] PHP allocating too much memory

On 15/06/2016 14:01, Peter LeBrun wrote: The weirdest part about this is that PHP is somehow trying to allocate 140TB of memory. I've seen numbers like that a few times - always around 140TB, but the exact number varies. I assume it's an overflow (or underflow?) somewhere, but the exact mecha

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/16 9:04 AM, Jordi Boggiano wrote: Just a thought here, if the goal is to provide a better interface, Hi Jordi, Iiuc, Leigh's goal, which I support, is to fix known bugs. It is not to provide a better interface. I already suggested that if people want new RNGs or a new API then we

Re: [PHP-DEV] PHP allocating too much memory

On 6/15/2016 6:07 AM, Jordi Boggiano wrote: On 15/06/2016 14:01, Peter LeBrun wrote: Hi - I'm getting the following error in php7.0.5: Fatal Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 140729445144864 bytes) If it's relevant, we're using dblib+freetds. I can't

Re: [PHP-DEV] PHP allocating too much memory

On 15-Jun-16 15:55, Rowan Collins wrote: On 15/06/2016 14:01, Peter LeBrun wrote: The weirdest part about this is that PHP is somehow trying to allocate 140TB of memory. I've seen numbers like that a few times - always around 140TB, but the exact number varies. I assume it's an overflow (or

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

On 15/06/2016 12:38, Jordi Boggiano wrote: On 15/06/2016 11:41, Pierre Joye wrote: I also understand the needs to change, update, optimize or clean our edge cases to open the path to JIT and the likes. However I would be very careful about that, and Dmitry and the team are very careful. I also h

[PHP-DEV] [RFC] Small proposal for ReflectionType improvements

As mentioned a day or two ago have a few proposed improvements for ReflectionType: https://wiki.php.net/rfc/ReflectionTypeImprovements It's pretty small but very useful. It has a small BC with the __toString representation of parameters with a default value of null to reflect the new nullabil

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

On 6/15/2016 12:27 PM, Alexander Lisachenko wrote: > For PHP7 we have pretty errors for almost everything, even eval can throw a > ParseError exception, but not for the require expression, because it's > still producing an uncatchable fatal errors: > > try { > require('no.php'); > } catch (Thr

Re: [PHP-DEV] PHP allocating too much memory

On Wed, Jun 15, 2016 at 11:34 AM, Michael Felt wrote: > > > On 15-Jun-16 15:55, Rowan Collins wrote: > >> On 15/06/2016 14:01, Peter LeBrun wrote: >> >>> The weirdest part about this is that PHP is somehow trying to allocate >>> 140TB of memory. >>> >> >> I've seen numbers like that a few times -

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

2016-06-15 19:38 GMT+02:00 Fleshgrinder : > On 6/15/2016 12:27 PM, Alexander Lisachenko wrote: > > For PHP7 we have pretty errors for almost everything, even eval can > throw a > > ParseError exception, but not for the require expression, because it's > > still producing an uncatchable fatal error

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

On 6/15/2016 1:38 PM, Jordi Boggiano wrote: > We are finally seeing more rapid PHP version adoption and I think it > would be a shame to break the trust PHP gained in the last few years of > stable and predictable releases. > Well spoken Sir! :) -- Richard "Fleshgrinder" Fussenegger signatur

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/2016 1:30 AM, Tom Worster wrote: > On 6/14/16 3:12 PM, Fleshgrinder wrote: > >> Call me ignorant but is this required in typical web applications? > > PHP is used for various things, not just web apps. I use it for various > other things because its the language in which I am most fluent.

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

On 6/15/2016 7:52 PM, Niklas Keller wrote: > I think it can go into 7.1. It's not a BC break, as it will still produce a > fatal error if the error isn't caught. > file_get_contents() and friends emit an E_WARNING and not an E_ERROR or worse. ;) -- Richard "Fleshgrinder" Fussenegger signatur

Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x

Oh, just read the require example, didn't read it was planned for all file functions. Fleshgrinder schrieb am Mi., 15. Juni 2016, 19:57: > On 6/15/2016 7:52 PM, Niklas Keller wrote: > > I think it can go into 7.1. It's not a BC break, as it will still > produce a > > fatal error if the error isn

Re: [PHP-DEV] [RFC] RNG fixes

Fleshgrinder schrieb am Mi., 15. Juni 2016, 19:55: > On 6/15/2016 1:30 AM, Tom Worster wrote: > > On 6/14/16 3:12 PM, Fleshgrinder wrote: > > > >> Call me ignorant but is this required in typical web applications? > > > > PHP is used for various things, not just web apps. I use it for various > >

Re: [PHP-DEV] [RFC] RNG fixes

On 6/15/2016 9:31 PM, Niklas Keller wrote: > Quoting from PHP.net: > > PHP is a popular general-purpose scripting language that is especially > suited to web development. > Quoting from Wikipedia: > PHP is a server-side scripting language designed for web development > but also used as a genera

[PHP-DEV] Deprecations PHP 7.1

What's the status here? https://wiki.php.net/rfc/deprecations_php_7_1 I do not have the thread in my history anymore so cannot reply directly to the actual thread. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecations PHP 7.1

Nikita, As I remember , you also liked to deprecate $errcontext argument of error handlers. http://php.net/manual/en/function.set-error-handler.php Thanks. Dmitry. From: Fleshgrinder Sent: Wednesday, June 15, 2016 10:58:30 PM To: php-internals; Nikita Popov

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

Le 06/06/2016 09:22, Dmitry Stogov a écrit : You can find the full RFC at: https://wiki.php.net/rfc/too_few_args I encourage everyone to read the RFC and cast your vote towards whichever option you feel is the best for the language and the community. Hi, At AFUP, we would be -1 for this RFC f

Re: [PHP-DEV] PHP allocating too much memory

Hey everyone, thanks for your help and input. We've narrowed it down to cases where there is string concatenation with a constant, but currently upgrading to 7.0.7 to see if that makes a difference. Enjoy your evening, Peter On Wed, Jun 15, 2016 at 1:50 PM, Trevor Suarez wrote: > On Wed, Jun

Re: [PHP-DEV] [RFC] RNG fixes

On Jun 16, 2016 2:43 AM, "Fleshgrinder" wrote: > > On 6/15/2016 9:31 PM, Niklas Keller wrote: > > Quoting from PHP.net: > > > > PHP is a popular general-purpose scripting language that is especially > > suited to web development. > > > > Quoting from Wikipedia: > > > PHP is a server-side scripting

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

Hi, On Jun 6, 2016 2:22 PM, "Dmitry Stogov" wrote: > > Hi, > > > This mini RFC has been moved to "Voting" state. Voting > began on Jun 6 and will close on June 16. > > You can find the full RFC at: https://wiki.php.net/rfc/too_few_args > > I encourage everyone to read the RFC and cast your vote t

Re: [PHP-DEV] PHP allocating too much memory

Hi On Jun 16, 2016 7:22 AM, "Peter LeBrun" wrote: > > Hey everyone, thanks for your help and input. We've narrowed it down to > cases where there is string concatenation with a constant, but currently > upgrading to 7.0.7 to see if that makes a difference. Is it possible to open a bug or post a

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

Morning, > This would keep the "BC promise" intact instead of going back to cowboy php days. > Please don't let's make it harder to go from 7.0 to 7.1 than it was from 5.6 to 7.0. Can we reduce hyperbole to nil, please. Before work starts on PHP 8, we need to have something worth br

[PHP-DEV] [RFC] [Accepted] Fix inconsistent behavior of $this variable

Hi internals, The RFC https://wiki.php.net/rfc/this_var was accepted by 43 against 0, and the corresponding patch was merged into master. Thanks. Dmitry.

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

Hi internals, The RFC https://wiki.php.net/rfc/too_few_args was accepted by 39 against 11, and the corresponding patch was merged into master. Thanks. Dmitry.

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

Hi Dmitry I am sorry but I have to ask to wait before merging it. It is definitely not clear that: . The rfc was valid to begin with due to the short discussion time . This BC is acceptable for 7.x I think things like things can be prevented by following the relatively simple rfc process and ha

Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?

On Jun 16, 2016 11:41 AM, "Joe Watkins" wrote: > > Morning, > >> This would keep the "BC promise" intact instead of going back to > cowboy php days. > >> Please don't let's make it harder to go from 7.0 to 7.1 than it was > from 5.6 to 7.0. > >Can we reduce hyperbole to nil, please. >

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

Hi Pierre, On 06/16/2016 09:18 AM, Pierre Joye wrote: Hi Dmitry I am sorry but I have to ask to wait before merging it. Sorry, but this is already merged. It is definitely not clear that: . The rfc was valid to begin with due to the short discussion time . This BC is acceptable for 7.x

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

The voting dates was changed to Jun 24 (to satisfy 2 weeks discussion period). In my opinion the BC break is minimal. Actually, the "wrong" behavior was reported by https://bugs.php.net/bug.php?id=71127 Before this, opcache worked "improperly" for few years (at least since php-5.4). Unfortuna