Re: [PHP-DEV] [RFC] JIT

Morning Dmitry, and internals, This is marvellous stuff, truly brilliant. I particularly appreciate the non-intrusive approach of setting jit'd code as the opcode handler, this makes life a little easier for hacky extension authors, I think. As others have said: I don't like the idea of

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On 01/02/2019 08:34, Kris Craig wrote: The more I think about this, the less I like it. According to the page linked to from the RFC, there are 51 current FIG members who would gain a vote. So this RFC would strip most contributers of their voting rights (including me), while simultaneously

Re: [PHP-DEV] [RFC] JIT

On 2/1/19 3:29 AM, Larry Garfield wrote: > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote: >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski wrote: >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen >>> >>> wrote: Without my usual Windows bias, I do believe it is a

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Thu, Jan 31, 2019 at 11:57 PM Stanislav Malyshev wrote: > Hi! > > I haven't fully read the RFC yet, so I'll come back with more formed > opinion about it probably, but wanted to comment about a couple of > points here: > > > Reasoning: If somebody is out of the project for 10 years they

Re: [PHP-DEV] RFC Abolish Narrow Margins

On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev wrote: > Hi! > > > Let me reply to the last point first, because I think that's really the > > crux here: The issue is not that this RFC is very urgent per se, it's > that > > it has already been delayed numerous times and it is imperative that

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, Jan 31, 2019 at 7:30 PM Rowan Collins wrote: > On Thu, 31 Jan 2019 at 07:34, Peter Kokot wrote: > > > Sorry, I didn't put my words correctly here. Not inconsistency. > > Inconsistency is a fact, yes. I've meant the incapability of doing > > something to fix this inconsistency. And it is

Re: [PHP-DEV] Deprecation ideas for PHP 8

> Deprecation notices won't change people's *desire* to change their code. If you raised a deprecation notice for every call to, say "htmlspecialchars", the only result would be people turning off deprecation notices, and missing more important deprecations. You have a point here. Couldn't we

Re: [PHP-DEV] Disable PEAR by default

+1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann wrote: > Am 01.02.2019 um 12:27 schrieb Nikita Popov: > > I would like to suggest that installation of PEAR is disabled by default > in > > PHP 7.4. PR: https://github.com/php/php-src/pull/3781 > > +1 > > -- > PHP Internals - PHP Runtime

Re: [PHP-DEV] Deprecation ideas for PHP 8

Den fre. 1. feb. 2019 kl. 12.34 skrev Benjamin Morel : > You have a point here. Couldn't we add a "deprecated log" feature, that > would log each deprecated function only once? At least we could leave an > app running for some time, and get a curated list of deprecated features > from the

Re: [PHP-DEV] [RFC] JIT

Hi, On 31.01.19 г. 18:47 ч., Kalle Sommer Nielsen wrote: Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov : On 1/31/19 7:01 PM, Nikita Popov wrote: On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov mailto:dmi...@zend.com>> wrote: Hi Internals, I'm glad to finally propose

Re: [PHP-DEV] Disable PEAR by default

Am 01.02.2019 um 12:27 schrieb Nikita Popov: I would like to suggest that installation of PEAR is disabled by default in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Fri, 1 Feb 2019 at 09:47, Yasuo Ohgaki wrote: > Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE) > names. > So there wouldn't be compatibility issues for CODING_STANDARD names. > I think this would be the worst of both worlds. We would have to permanently document two

Re: [PHP-DEV] [RFC] JIT

On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. > How so? I tend to disagree here. Except if recent changes affect Windows indirectly (as in optimization done on linux only). Also while

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, 31 Jan 2019 at 22:39, Benjamin Morel wrote: >> What if people's muscle memory, their coding standards, their need for progressive compatibility, their tools, the tutorials they follow, the code snippets they copy, all make it easier to just keep using the old names? >> Then our

[PHP-DEV] Disable PEAR by default

Hi internals, I would like to suggest that installation of PEAR is disabled by default in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 I think the reasons for this should be obvious. It's not really the recent security breach itself, but rather the underlying issue that PEAR simply

Re: [PHP-DEV] [RFC] JIT

Pierre, On 1.02.19 г. 13:12 ч., Pierre Joye wrote: On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov I don't see any problems with including JIT without Windows support. Windows runs PHP much slower any way. How so? I tend to disagree here. Except if recent changes affect Windows indirectly

Re: [PHP-DEV] [RFC] JIT

On Fri, Feb 1, 2019 at 1:09 PM Nikita Popov wrote: > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov wrote: > >> Hi Internals, >> >> >> I'm glad to finally propose including JIT into PHP. >> >> >> https://wiki.php.net/rfc/jit >> >> >> In the current state it may be included both into PHP-8,

Re: [PHP-DEV] [RFC] JIT

On 2/1/19 3:09 PM, Nikita Popov wrote: > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > wrote: > > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be

Re: [PHP-DEV] [RFC] JIT

On 2/1/19 4:23 PM, Nikita Popov wrote: > On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov > wrote: > > > > On 2/1/19 11:55 AM, Joe Watkins wrote: > > Morning Dmitry, and internals, > > > > This is marvellous stuff, truly brilliant. I particularly >

Re: [PHP-DEV] [RFC] JIT

On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov wrote: > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we are > going to continue active improvement, and into PHP-7.4,

Re: [PHP-DEV] [RFC] JIT

On 2/1/19 2:12 PM, Pierre Joye wrote: > > > On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov wrote: > > > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. > > > How so? I tend to disagree here.

Re: [PHP-DEV] [RFC] JIT

On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov wrote: > > > On 2/1/19 11:55 AM, Joe Watkins wrote: > > Morning Dmitry, and internals, > > > > This is marvellous stuff, truly brilliant. I particularly appreciate the > > non-intrusive approach of setting jit'd code as the opcode handler, this > >

Re: [PHP-DEV] [RFC] JIT

On 2/1/19 11:55 AM, Joe Watkins wrote: > Morning Dmitry, and internals, > > This is marvellous stuff, truly brilliant. I particularly appreciate the > non-intrusive approach of setting jit'd code as the opcode handler, this > makes life a little easier for hacky extension authors, I think. >

Re: [PHP-DEV] Remove zpp variation tests

On Wed, Jan 30, 2019 at 7:39 PM Stanislav Malyshev wrote: > Hi! > > > This test passes a certain set of input values of different types to a > > function with a zpp string argument and observes the behavior. Of course, > > there are also hundreds of other functions that accept strings through >

Re: [PHP-DEV] [RFC] JIT

On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote: > On 2/1/19 3:29 AM, Larry Garfield wrote: > > Question from a non-compiler-engineer: Could we end up in a situation > > where > > future language features (in 8.3 or something) are only performant on JIT- > > enabled platforms? I

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Friday, February 1, 2019 2:34:12 AM CST Kris Craig wrote: > On Thu, Jan 31, 2019 at 11:57 PM Stanislav Malyshev > > wrote: > > Hi! > > > > I haven't fully read the RFC yet, so I'll come back with more formed > > opinion about it probably, but wanted to comment about a couple of > > > >

Re: [PHP-DEV] Deprecation ideas for PHP 8

Totally agree with this. The new and old can exist both. We should be open to change. On Thu, 31 Jan 2019, 11:53 Benjamin Morel Please forgive my stubborness, too. I fail to see how WordPress supporting > PHP versions that have been EOL for YEARS can be of any help to the > community? These

Re: [PHP-DEV] Re: patch for imap bug 77153

Zitat von Bishop Bettini : On Wed, Nov 21, 2018 at 7:27 PM Stanislav Malyshev wrote: Hi! > Anyhow, this is water under the bridge now, and I think we should issue > a call for maintainership[4] for ext/imap as soon as possible, since > this is not the only issue[5] of this unmaintained[6]

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

All, I have managed to avoid commenting on PHP-FIG since the group was dissolved, then re-constituted under the same name, without my participation as one of its original founding members. However, I cannot let this phrasing pass: On Feb 1, 2019, at 10:30, Larry Garfield wrote: > FIG today

Re: [PHP-DEV] [RFC] JIT

On Fri, 1 Feb 2019 at 13:12, Dmitry Stogov wrote: > >I'm not keen on the idea of merging this into 7.4, for various > > reasons that don't need to be repeated. > > OK. It's not only your opinion. > You may vote against, and persuade others. > I think it would be interesting to clarify the

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Thu, 31 Jan 2019 at 13:44, Zeev Suraski wrote: > > Without further ado, an RFC that’s attempting to comprehensively solve many > of the issues that have plagued our RFC process since it was hastily > introduced in 2011: Hi Zeev, Please can you very clearly state what problem you are trying

Re: [PHP-DEV] Re: patch for imap bug 77153

On Fri, Feb 1, 2019 at 11:45 AM Jan Schneider wrote: > > Zitat von Bishop Bettini : > > > On Wed, Nov 21, 2018 at 7:27 PM Stanislav Malyshev > > wrote: > > > >> Hi! > >> > >> > Anyhow, this is water under the bridge now, and I think we should > issue > >> > a call for maintainership[4] for

Re: [PHP-DEV] [RFC] JIT

On Thu, Jan 31, 2019 at 9:01 AM Nikita Popov wrote: > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov wrote: > > > Hi Internals, > > > > > > I'm glad to finally propose including JIT into PHP. > > > > > > https://wiki.php.net/rfc/jit > > > > > > In the current state it may be included both into

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On 01/02/2019 18:13, Dan Ackroyd wrote: > btw, you seem to have completely overlooked extension maintainers from > your list of people who should have a vote on PHP internals. And those who have involved themselves in writing tests for PHP through events like TestFests, and who probably have

Re: [PHP-DEV] [RFC] JIT

On Sat, Feb 2, 2019, 12:46 AM Levi Morrison I strongly with Nikita's points on cost/benefit analysis. I have > written a lot but thrown it away because I think this point is so > important: > > It appears that the JIT does not work on Clang or MSVC compilers. It must some changes needed for php

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Hi, Regarding the definitions of what constitutes a Change, a Packaging Decision and an Implementation Decision, I think it does a better job than the current voting RFC but IMHO it still is over-complicated. Trying to specify which changes are which just for the sake of allowing some things to

Re: [PHP-DEV] Disable PEAR by default

Hello, On Fri, 1 Feb 2019 at 12:44, Joe Watkins wrote: > > +1 > > On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann wrote: > > > Am 01.02.2019 um 12:27 schrieb Nikita Popov: > > > I would like to suggest that installation of PEAR is disabled by default > > in > > > PHP 7.4. PR:

Re: [PHP-DEV] Disable PEAR by default

On 2/1/19 5:08 PM, Alice Wonder wrote: On 2/1/19 3:06 PM, Peter Kokot wrote: Hello, On Fri, 1 Feb 2019 at 12:44, Joe Watkins wrote: +1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann wrote: Am 01.02.2019 um 12:27 schrieb Nikita Popov: I would like to suggest that installation of PEAR

Re: [PHP-DEV] Disable PEAR by default

Hello, On Sat, 2 Feb 2019 at 02:08, Alice Wonder wrote: > I do not like composer. A problem I have encountered, a project > specifies a version for a dependency. > > That version has vulnerability, developer fixed it in newer release, but > composer keeps pulling in the older version because

Re: [PHP-DEV] Disable PEAR by default

> Many PEAR packages are maintained, and they are globally installed > meaning when a vulnerability is found, there is one to be fixed and > everything on the system is fixed. Which is great. Practice showed that global PHP packages are not that good actually and managing dependencies on a local

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Fri, Feb 1, 2019 at 8:41 PM Johannes Schlüter wrote: > On Do, 2019-01-31 at 14:28 -0500, Bishop Bettini wrote: > > > >2. Core developers are defined as the top 13 committers within the > >period of two years since voting began. A core developer is a de > > facto > >community

Re: [PHP-DEV] Disable PEAR by default

It's ok that you don't like Composer. You can find or even create a new tool which fit you needs. The reason we are talking about PEAR here, is it's bundled in the core, and no one is maintaining it. We are not saying Composer should be included into the core, at least not this thread.

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

On Do, 2019-01-31 at 14:28 -0500, Bishop Bettini wrote: > >    2. Core developers are defined as the top 13 committers within the >    period of two years since voting began. A core developer is a de > facto >    community member, but caucuses as a core developer. How do you define "top 13

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield : > Disclosure: I am a long-time member of PHP-FIG, but I am NOT speaking on > behalf of FIG in this post, only for myself. > > As Zeev noted, I think it's very good to have some mechanism for formal > involvement from people who aren't C

Re: [PHP-DEV] Disable PEAR by default

On 2/1/19 3:06 PM, Peter Kokot wrote: Hello, On Fri, 1 Feb 2019 at 12:44, Joe Watkins wrote: +1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann wrote: Am 01.02.2019 um 12:27 schrieb Nikita Popov: I would like to suggest that installation of PEAR is disabled by default in PHP 7.4. PR:

Re: [PHP-DEV] Disable PEAR by default

On 2/1/19 5:12 PM, Peter Kokot wrote: Hello, On Sat, 2 Feb 2019 at 02:08, Alice Wonder wrote: I do not like composer. A problem I have encountered, a project specifies a version for a dependency. That version has vulnerability, developer fixed it in newer release, but composer keeps pulling

Re: [PHP-DEV] Disable PEAR by default

On 1 February 2019 23:06:41 GMT+00:00, Peter Kokot wrote: >Q2: Follow up question, what to do with PECL scrip then? Is in PHP >even possible to start a new project such as a pecl command line tool >that would offer a replacement for current pecl script? It's certainly possible, and was the aim