Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

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 omitting to support windows, less worried about
fancy architectures.
  I'm not keen on the idea that there is no way to debug the code this
generates outside of GDB, and I'm not sure how useful gdb will be: I've
tried to debug JIT'd code in that before and it doesn't do so well, but I
could easily have been doing it wrong. I'd be very happy to be corrected
about this ?
  I'm not keen on the idea of merging this into 7.4, for various reasons
that don't need to be repeated.

Bottom line though, I love it, it's brilliant, and look forward to PHP 8.

Thank you, Dmitry.

Cheers
Joe


On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  wrote:

>
>
> 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 considerable fact
>  like Nikita pointed out as Windows is a first class citizen in terms
>  of operating systems we support. While PHP on Windows may not have the
>  speed that the Unix counterpart have, it is still a very important
>  development platform. Many developers develop on Windows and deploy on
>  a Unix based system, being unable to test such an important feature in
>  a development environment is also a large question mark.
> >>>
> >>> As long as we can agree that very few actually *deploy *on Windows, I
> >>> think
> >>> we're on solid grounds.
> >>> As the JIT implementation is likely to have at least *some* significant
> >>> differences compared to Linux, I'm not sure what testing it on Windows
> >>> would give you.  JIT is supposed to be entirely transparent, and the
> >>> performance characteristics - as well as the bug patterns - are likely
> to
> >>> be quite different on Linux vs. Windows, at least in many cases.
> >>> Is it really that important to have?
> >>>
> >>> I'm honestly a bit perplexed by how many people here viewing Windows
> >>> support as a must have, while at the same time I think we all agree
> PHP is
> >>> very scarcely found on production Windows servers, and JIT is a
> >>> predominantly production feature.
> >>>
> >>> I'm personally interested in taking a look at it (and I'm certain
> >>>
>  Anatol does too), but simply dismissing is a no-go for me.
> >>>
> >>> It'd be interesting to evaluate the cost associated with supporting
> >>> Windows.  Bare in mind, we're proposing to vote on this as a production
> >>> feature for PHP 8 - which realistically means almost two years from now
> >>> *at
> >>> the earliest*.  I'm sure we'd have Windows support a lot sooner than
> that
> >>> if we decide that it's a must have.  I agree with Nikita that the key
> >>> question is in fact, do we or do we not want to introduce JIT in - with
> >>> the
> >>> main question being the maintenance cost.  Let's tackle this question
> >>> first, otherwise - why send Dmitry (and maybe others) for doing more
> work
> >>> (Windows support) if we are likely to flush it all down the toilet?
> >>>
> >> Maybe we're the only ones, but we run production PHP on Windows. I have
> no
> >> issues with the idea of not initially having support for Windows. I can
> >> probably even live with never having support for Windows - provided
> that we
> >> don't find ourselves in a situation like Nikita mentioned where features
> >> start getting developed in PHP instead of C and require JIT in order to
> >> function.
> >
> > 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 know there were some RFCs rejected in the past on
> the
> > grounds that they involved too many runtime checks (and thus a
> performance
> > hit); if it were possible for a JIT to optimize some of those away, it
> might
> > make the cost acceptable.  However, if a JIT only works on some systems
> that
> > might widen the gap between have- and have-not platforms.
>
> I think, JIT only approach doesn't make a lot of sense for PHP, with one
> of the most fast VM. And this is a trend. Even V8, starting from JIT
> only, switched back to VM+JIT.
>
> Thanks. Dmitry.
>
> >
> > Is that a concern, or am I making things up?  Or, is it a concern but
> we're
> > legit OK with that happening (which is also an entirely valid decision to
> > make)?
> >
> > --Larry Garfield
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Lester Caine]

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 adding 51 new voters, all from the
same external organization (one that has been aggressively gunning for
"official" recognition since its inception).  In other words, this RFC, in
its current form, would have effectively handed control over the entire PHP
project to FIG.  Though I'm sure it was never the intent, TBH, this does
feel like a bit of a slap in the face to past contributors who still have
good ideas to offer now and then and should still have a voice.


The question of the whether FIG is to become a core standard and 
everything is then based of it is perhaps the real RFC here? That move 
would bring FIG developers in simply because their contributions would 
be direct to the PHP code base? That it does now seem to be the de-facto 
standard may detract from a formal discussion as to if it should be THE 
roadmap moving forward? Much like composer is now so enshrined in new 
projects but is at adds with much legacy code? Bringing in blocks of 
'voters' who have a different development style before deciding if that 
style is acceptable just seems wrong?


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

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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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 considerable fact
 like Nikita pointed out as Windows is a first class citizen in terms
 of operating systems we support. While PHP on Windows may not have the
 speed that the Unix counterpart have, it is still a very important
 development platform. Many developers develop on Windows and deploy on
 a Unix based system, being unable to test such an important feature in
 a development environment is also a large question mark.
>>>
>>> As long as we can agree that very few actually *deploy *on Windows, I
>>> think
>>> we're on solid grounds.
>>> As the JIT implementation is likely to have at least *some* significant
>>> differences compared to Linux, I'm not sure what testing it on Windows
>>> would give you.  JIT is supposed to be entirely transparent, and the
>>> performance characteristics - as well as the bug patterns - are likely to
>>> be quite different on Linux vs. Windows, at least in many cases.
>>> Is it really that important to have?
>>>
>>> I'm honestly a bit perplexed by how many people here viewing Windows
>>> support as a must have, while at the same time I think we all agree PHP is
>>> very scarcely found on production Windows servers, and JIT is a
>>> predominantly production feature.
>>>
>>> I'm personally interested in taking a look at it (and I'm certain
>>>
 Anatol does too), but simply dismissing is a no-go for me.
>>>
>>> It'd be interesting to evaluate the cost associated with supporting
>>> Windows.  Bare in mind, we're proposing to vote on this as a production
>>> feature for PHP 8 - which realistically means almost two years from now
>>> *at
>>> the earliest*.  I'm sure we'd have Windows support a lot sooner than that
>>> if we decide that it's a must have.  I agree with Nikita that the key
>>> question is in fact, do we or do we not want to introduce JIT in - with
>>> the
>>> main question being the maintenance cost.  Let's tackle this question
>>> first, otherwise - why send Dmitry (and maybe others) for doing more work
>>> (Windows support) if we are likely to flush it all down the toilet?
>>>
>> Maybe we're the only ones, but we run production PHP on Windows. I have no
>> issues with the idea of not initially having support for Windows. I can
>> probably even live with never having support for Windows - provided that we
>> don't find ourselves in a situation like Nikita mentioned where features
>> start getting developed in PHP instead of C and require JIT in order to
>> function.
> 
> 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 know there were some RFCs rejected in the past on the
> grounds that they involved too many runtime checks (and thus a performance
> hit); if it were possible for a JIT to optimize some of those away, it might
> make the cost acceptable.  However, if a JIT only works on some systems that
> might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one 
of the most fast VM. And this is a trend. Even V8, starting from JIT 
only, switched back to VM+JIT.

Thanks. Dmitry.

> 
> Is that a concern, or am I making things up?  Or, is it a concern but we're
> legit OK with that happening (which is also an entirely valid decision to
> make)?
> 
> --Larry Garfield
> 

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

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

[Kris Craig]

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 probably
> > lost track on how the language and needs evolved and just voting since
> > an old friend needed a deciding vote is bad.
>
> I agree, though "out of project" can differ... But I think if the person
> had made no contribution for a decade, then probably he wouldn't be very
> well informed voter. Easier way would be to make the list of such people
> and let them ask on the list that their vote will be kept if they want
> to, with explanation on how they plan to continue contribute (we don't
> have to require actual contribution, just people promising to do so - we
> are all volunteers here anyway). People that have long moved on would
> just ignore that, and people who want to come back will do so.
>
> > For groups like FIG I am uncertain. I think it is a good thing if we
> > push more things out of PHP itself into the userspace (JIT, FFI, ...
> > allow more and more stuff to be done in userspace) and thus
> > coordinating with userspace developers and setting standards and
> > interoperability there is good. However it are the maintainers who
> > (often voluntarily) have to maintain these things and overruling actual
> > maintainers is bad as they lose interest.
>
> Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having
> input from major userspace groups is great. But having input and having
> deciding voice is a different thing. Discussion and vote are different
> processes, both important but with different results. So I wonder if we
> can't find some venue to collect this feedback without having people who
> aren't core developers decide for core developers what should they do.
> This sounds like something that won't be healthy.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
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 adding 51 new voters, all from the
same external organization (one that has been aggressively gunning for
"official" recognition since its inception).  In other words, this RFC, in
its current form, would have effectively handed control over the entire PHP
project to FIG.  Though I'm sure it was never the intent, TBH, this does
feel like a bit of a slap in the face to past contributors who still have
good ideas to offer now and then and should still have a voice.
Furthermore, it seems strange to me that a provision with such massive and
far-reaching implications would be quietly buried at the bottom of an RFC
filled with otherwise popular, non-controversial ideas.

There are a lot of people like me who, while we may not be active core
contributors, we have contributed in different ways over the years and we
deserve better than to be pushed aside like this.  I dedicated a full year
of my life to this project and made a number of contributions to our test
automation during that time, as well as put a lot of time into testing and
debugging during the 5.3.3 release cycle.  To say that I should be denied a
vote now only serves to discourage me from being active again in the
future.  While I agree that we should tighten-up our standards regarding
who gets to vote, I am increasingly convinced that attempting to apply it
retroactively to existing contributors at all would be a mistake.  It just
looks like a solution in search of a problem, seeing as how most of those
inactive people don't vote anymore, anyway.  Furthermore, having a more
diverse voter base that includes people not directly involved with the
day-to-day core work helps to prevent any changes that would be wildly
unpopular with the community from being rubber-stamped.

I'm sorry but I must repeat my request that this provision be removed and
placed in a separate RFC.  I don't see how there's any way I'd be able to
support this otherwise.  Are you outright refusing to split it up or are
you open to discussing it in light of these concerns that have been raised
by myself and others?

--Kris

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

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 we
> > prevent that from happening again. Since this issue was first raised, a
>
> That's understandable. But I think if we have an ongoing discussion now,
> waiting until this discussion comes to some conclusion or at least
> giving it some reasonable time to do so is a good thing. Note the
> "reasonable" part - it doesn't mean it should wait another 2 years. But
> if 2+ year old RFC is revived I think it's reasonable to wait a week or
> two with vote. Original margins were meant for situation where somebody
> puts up RFC and immediately proceeds to vote, not for situation where
> RFC lies dormant for 2 years, then revived and immediately proceeds to
> vote without most people even remembering what happened 2 years ago. I
> think in this case it's reasonable to wait a little bit - and I don't
> see a reason why not.
>

That's reasonable. What is important to me is that:

a) We don't vote RFCs with low margins in the meantime. As a show of good
faith, it would be nice to adjust the vote in the JIT RFC to require a 2/3
majority.

b) The voting margin question is resolved separately from other concerns. I
very specifically do not want this bundled with anything else. I don't want
the voting margin adjustment to fail because of other changes bundled in
the same RFC. Conversely, I do not want other changes in the same RFC to
pass simply because it's the only way to get the voting margin changes.

Nikita

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

[Yasuo Ohgaki]

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 becoming some sort of
> > stubborn belief and less and less people want to fix it.
> >
> > The RFC: Consistent function names [1] shows the magnitude of this. I
> > don't think every function listed there needs a change so it can be
> > greatly reduced. But still this can be done in several years to 10
> > years or so (measuring over the thumb).
> >
>
>
> Hi,
>
> I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
> the fundamental problem: the effort needed is not on the part of a few
> volunteers changing the language, it is effort by *every single user of the
> language*, rewriting *every single PHP program ever written*.
>
> WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
> 7.3, released a couple of months ago; one of their biggest challenges in
> raising that bar is that they, too, have to persuade a community (the theme
> and plugin authors) to change their code to match. That should give you
> some idea of how long old and new names would have to exist side by side,
> while we waited for everyone to rewrite all their code, and meanwhile, the
> language would be *even more inconsistent*, because there would be extra
> ways of writing the same thing.
>

Hi,

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.

Christoph suggests namespace for renaming function. This works also.
If namespace is used, it is better to have "PHP" namespace to keep user
namespace clean. IMO.
e.g. PHP\BC\add()
This creates yet another inconsistency with existing modules, though.

Bottom line is almost all developers dislike inconsistent names, prefer
to enter extra few chars.

Consistent name isn't big deal, but keeping inconsistent names for good
doesn't sound nice.

Regards,

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

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

[Benjamin Morel]

>  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 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 deprecated log.



On Fri, 1 Feb 2019 at 11:11, Rowan Collins  wrote:

> 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 "deprecation" means nothing, and we are stuck with a long list
> of aliases to maintain, and people learning the language scratching their
> heads at inconsistent examples.
>
> > Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
> example, strikes through deprecated method names), and static code analysis
> tools.
>
> 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.
>
>
> >>  ... although it takes us close to "completely new language"
> territory.
>
> > Maybe not, if this can be done in a mostly BC way.
>
> It wasn't the BC I was worrying about there, but the possibility that
> projects would adopt one style or the other, and readers coming from an
> "old-style" project might find the code in a "new-style" project rather
> alien. In a worst case scenario, it would feel like we had two languages
> interoperating on the same runtime, like when HHVM hosted both PHP and
> Hack. It's not inevitable, though, just a risk to think about if we ever
> get to that position.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Disable PEAR by default

[Joe Watkins]

+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 Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Kalle Sommer Nielsen]

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 deprecated log.

I would oppose such a feature as it would make deprecations even more
redundant than disabling them. While they are annoying, they are also
a helpful message to inform our users that this functionality will not
be around, blindly ignoring it and further more giving it its own log
file that doesn't grow nearly as much seems like a bad way to solve
this.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] [RFC] JIT

[Andrey Hristov]

 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 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, as an
 experimental feature.


 Thanks. Dmitry.


This has been a long time on the horizon, nice to see this finally
moving forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

   * Significantly better performance for numerical code.
   * Slightly better performance for "typical" PHP web application code.
   * The potential to move more code from C to PHP, because PHP will now
be sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are
about 3-4 people who I would trust to carry out a non-trivial language
change, which will require touching the compiler, the virtual machine,
the optimizer and the persistence layer. Each of those components is
quite complex, in different ways. Some people who are comfortable with
doing VM changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT
is dynasm based, the core JIT code is essentially written in raw x86
assembly. This will further limit the pool of people who will be able to
make non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial
PHP 7.3 release suffered from substantial stability issues, more than
new minor version releases tend to do. I think there are multiple
reasons for that (and we might want to start a conversation about our QA
processes in a separate thread), but one main contributing factor were
opcache optimizer bugs. Compiler optimizations are tricky and hard to
verify, and we often only learn about issues once the optimizer makes
contact with production codebases, which feature a much richer
collection of code patterns than our test suite. One can wonder whether
the relatively minor speedups we get from our optimization framework are
really worth having these stability issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs
in the JIT. These are probably going to be hard to debug, as we'll have
to drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we
decide to more parts of our C code into PHP because PHP is fast enough
with a JIT, that will of course only be true for platforms that actually
have JIT support. I'm not terribly concerned about loosing out some
performance on MIPS, but we do need to make sure that all our main
platforms are supported (Windows is a must there, imho).


I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.


Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.


in the age of CI systems it doesn't matter much what your primary local 
development platform is, even if it is different than the targeted 
platform. One creates a PR, pushes, CI triggers, checks validity, could 
be performance tested, and that's the real environment.
And not to mention containers for local development when the code is 
actually run in a Linux container, no matter whether running on Win, 
Linux or Mac.



I'm personally interested in taking a look at it (and I'm certain
Anatol does too), but simply dismissing is a no-go for me.



Best,
Andrey

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

Re: [PHP-DEV] Disable PEAR by default

[Sebastian Bergmann]

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

[Rowan Collins]

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 different names for every function, examples
(outside of php.net) would still have the old names in, people would
disagree about which to use, and the situation would be more confusing to
new users, not less. This already happens with count() vs sizeof() - people
get used to one or the other, and are confused when they see the other in
someone else's code.


> Bottom line is almost all developers dislike inconsistent names, prefer
> to enter extra few chars.

I think almost all developers would like to spend their effort making
material improvements to the robustness or functionality of their code.
That might include replacing htmlspecialchars with a smarter escaping or
"taint" tracking system; but it woudln't include renaming it in all their
code bases, or debating which of two valid names to use in a new codebase.

Let's focus our effort on writing improved features, and giving them good
names, and if that means some of the older functions become less necessary,
that's a bonus.

>
Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] JIT

[Pierre Joye]

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 I use php on windows less, I still see a large amount of
companies using php on windows,  in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.

>

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

[Rowan Collins]

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 "deprecation" means nothing, and we are stuck with a long list
of aliases to maintain, and people learning the language scratching their
heads at inconsistent examples.

> Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
example, strikes through deprecated method names), and static code analysis
tools.

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.


>>  ... although it takes us close to "completely new language"
territory.

> Maybe not, if this can be done in a mostly BC way.

It wasn't the BC I was worrying about there, but the possibility that
projects would adopt one style or the other, and readers coming from an
"old-style" project might find the code in a "new-style" project rather
alien. In a worst case scenario, it would feel like we had two languages
interoperating on the same runtime, like when HHVM hosted both PHP and
Hack. It's not inevitable, though, just a risk to think about if we ever
get to that position.

Regards,
-- 
Rowan Collins
[IMSoP]

[PHP-DEV] Disable PEAR by default

[Nikita Popov]

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
isn't actively maintained anymore.

Currently PEAR is broken on master due to the removal of each(), which was
deprecated in PHP 7.2. Apparently, since that time nobody noticed that PEAR
is throwing deprecation errors, or at least nobody bothered to fix them.
(I've submitted https://github.com/pear/Console_Getopt/pull/3 to fix at
least this particular issue.)

It's somewhat unfortunate that PEAR and PECL are coupled projects, but I
don't think that should prevent us from changing this default.

Regards,
Nikita

Re: [PHP-DEV] [RFC] JIT

[Andrey Hristov]

 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 (as in optimization done on linux only).

Also while I use php on windows less, I still see a large amount of
companies using php on windows,  in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.


considering how open is Microsoft to open source nowadays it is probably 
a no brainer to have them help. They might only need some hinting :)








Cheers,
Andrey


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

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

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, where we are
>> going to continue active improvement, and into PHP-7.4, as an experimental
>> feature.
>>
>>
>> Thanks. Dmitry.
>>
>
> I would like to check if the JIT provides an improvement for PHP-Parser.
> Unfortunately I'm getting a segfault when running the tests. Should be
> reproducible with
>
> git clone g...@github.com:nikic/PHP-Parser.git
> cd PHP-Parser
> composer install
> php-jit vendor/bin/phpunit
>
> I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT:
> It hangs when the script starts running, on line Zend/zend_gdb.c:84 in
> zend_gdb_register_code. I don't know if that's a bug or I need to do
> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
> 8.1.0.20180409-git).
>
> Nikita
>

Another project that I would like to test is amp
(g...@github.com:amphp/amp.git).
Here I am getting a segfault only on shutdown, after tests finished
running. However there are a number of test failures, all basically looking
the same:

1) Amp\Test\AllTest::testPendingPromiseArray
TypeError: Return value of Amp\Loop\Internal\TimerQueue::removeAndRebuild()
must be an instance of Amp\Loop\Internal\TimerQueueEntry, null returned

/home/nikic/amp/lib/Loop/Internal/TimerQueue.php:100
/home/nikic/amp/lib/Loop/Internal/TimerQueue.php:64
/home/nikic/amp/lib/Loop/NativeDriver.php:107
/home/nikic/amp/lib/Loop/Driver.php:134
/home/nikic/amp/lib/Loop/Driver.php:72
/home/nikic/amp/lib/Loop.php:84
/home/nikic/amp/test/AllTest.php:52

Here is the line that incorrectly gets a null:
https://github.com/amphp/amp/blob/c6f8425473ecc1cfc6909cf42b39abb39a11c837/lib/Loop/Internal/TimerQueue.php#L100

Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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 included both into PHP-8, where we
> are going to continue active improvement, and into PHP-7.4, as an
> experimental feature.
> 
> 
> Thanks. Dmitry.
> 
> 
> I would like to check if the JIT provides an improvement for PHP-Parser. 
> Unfortunately I'm getting a segfault when running the tests. Should be 
> reproducible with
> 
> git clone g...@github.com:nikic/PHP-Parser.git
> cd PHP-Parser
> composer install
> php-jit vendor/bin/phpunit
> 
> I tried to debug this. Unfortunately my gdb doesn't seem to work with 
> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84 
> in zend_gdb_register_code. I don't know if that's a bug or I need to do 
> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3) 
> 8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the 
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but 
most probably, only on next week.

Thanks. Dmitry.

> 
> Nikita

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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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
> 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 omitting to support windows, less
> worried
>  > about fancy architectures.
> 
> I can provide help to people who will going to implement JIT support
> for
> Windows. This is not going to be easy, because MSVC doesn't support
> "hybrid VM" and "global register variables", therefore the code is
> going
> to be more expensive.
> 
> 
> I think an important point here is that this issue affects not only 
> Windows: It also affects any platform that uses clang as their compiler. 
> Notably this includes MacOS.
> 
> Clang theoretically supports global registers, but only for 
> non-allocatable regs (rsp and rbp), which I think is not very useful for 
> this purpose.

We will have to provide a patch for CLANG, implementing PHP VM calling 
convention (HHVM, Erlang, Haskel did this).

Thanks. Dmitry.

> 
> So this problem needs to be solved not just for Windows support, but 
> also for MacOS support (and also FreeBSD and other clang-using platforms).
> 
> Nikita
> 
>  >    I'm not keen on the idea that there is no way to debug the
> code this
>  > generates outside of GDB, and I'm not sure how useful gdb will
> be: I've
>  > tried to debug JIT'd code in that before and it doesn't do so
> well, but
>  > I could easily have been doing it wrong. I'd be very happy to be
>  > corrected about this ?
> 
> I'm not sure, what is wrong with GDB, and if any other debuggers have
> special API for run-time generated code.
> 
>  >    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.
> 
> Thanks. Dmitry.
> 
>  >
>  > Bottom line though, I love it, it's brilliant, and look forward
> to PHP 8.
>  >
>  > Thank you, Dmitry.
>  >
>  > Cheers
>  > Joe
>  >
>  >
>  > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  
>  > >> wrote:
>  >
>  >
>  >
>  >     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
> mailto:z...@php.net>
>  >     >> wrote:
>  >      >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
>  >     mailto:ka...@php.net>  >>
>  >      >>>
>  >      >>> wrote:
>  >       Without my usual Windows bias, I do believe it is a
>  >     considerable fact
>  >       like Nikita pointed out as Windows is a first class
> citizen in
>  >     terms
>  >       of operating systems we support. While PHP on Windows
> may not
>  >     have the
>  >       speed that the Unix counterpart have, it is still a
> very important
>  >       development platform. Many developers develop on
> Windows and
>  >     deploy on
>  >       a Unix based system, being unable to test such an important
>  >     feature in
>  >       a development environment is also a large question mark.
>  >      >>>
>  >      >>> As long as we can agree that very few actually *deploy *on
>  >     Windows, I
>  >      >>> think
>  >      >>> we're on solid grounds.
>  >      >>> As the JIT implementation is likely to have at least *some*
>  >     significant
>  >      >>> differences compared to Linux, I'm not sure what testing
> it on
>  >     Windows
>  >      >>> would give you.  JIT is supposed to be entirely transparent,
>  >     and the
>  >      >>> performance characteristics - as well as the bug
> patterns - are
>  >     likely to
>  >      >>> be quite different on Linux vs. Windows, at least in
> many cases.
>  >      >>> Is it really that important to have?
>  >      >>>
>  >      >>> I'm honestly a bit perplexed by how many people here viewing
>  >     Windows
>  >      >>> support as a must have, while at the same time I think
> we all
>  >     agree PHP is
>  >      >>> very scarcely found on production Windows servers, and
> JIT is a
>  >      >>> predominantly production feature.
>  >     

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

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, as an experimental
> feature.
>
>
> Thanks. Dmitry.
>

I would like to check if the JIT provides an improvement for PHP-Parser.
Unfortunately I'm getting a segfault when running the tests. Should be
reproducible with

git clone g...@github.com:nikic/PHP-Parser.git
cd PHP-Parser
composer install
php-jit vendor/bin/phpunit

I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT:
It hangs when the script starts running, on line Zend/zend_gdb.c:84 in
zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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. Except if recent changes affect Windows 
> indirectly (as in optimization done on linux only).

More or less right. PHP uses GCC extensions, that are not available in MSVC.

> Also while I use php on windows less, I still see a large amount of 
> companies using php on windows,  in similar ways than on Linux.
> 
> Nikita concerns are valid, PHP is and should remain a cross platform 
> language. And some top OSes besides linux should remain a target. Easier 
> said than done and willing to help at least for windows. I am sure msft 
> teams will step in as well.

It would be great, if MSFT team helps.
I definitely, can't move JIT forward, and provide support for all 
platforms at the same time.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

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
> > makes life a little easier for hacky extension authors, I think.
> >
> > As others have said:
> >
> >I don't like the idea of omitting to support windows, less worried
> > about fancy architectures.
>
> I can provide help to people who will going to implement JIT support for
> Windows. This is not going to be easy, because MSVC doesn't support
> "hybrid VM" and "global register variables", therefore the code is going
> to be more expensive.
>

I think an important point here is that this issue affects not only
Windows: It also affects any platform that uses clang as their compiler.
Notably this includes MacOS.

Clang theoretically supports global registers, but only for non-allocatable
regs (rsp and rbp), which I think is not very useful for this purpose.

So this problem needs to be solved not just for Windows support, but also
for MacOS support (and also FreeBSD and other clang-using platforms).

Nikita


> >I'm not keen on the idea that there is no way to debug the code this
> > generates outside of GDB, and I'm not sure how useful gdb will be: I've
> > tried to debug JIT'd code in that before and it doesn't do so well, but
> > I could easily have been doing it wrong. I'd be very happy to be
> > corrected about this ?
>
> I'm not sure, what is wrong with GDB, and if any other debuggers have
> special API for run-time generated code.
>
> >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.
>
> Thanks. Dmitry.
>
> >
> > Bottom line though, I love it, it's brilliant, and look forward to PHP 8.
> >
> > Thank you, Dmitry.
> >
> > Cheers
> > Joe
> >
> >
> > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  > > wrote:
> >
> >
> >
> > 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
> > mailto:ka...@php.net>>
> >  >>>
> >  >>> wrote:
> >   Without my usual Windows bias, I do believe it is a
> > considerable fact
> >   like Nikita pointed out as Windows is a first class citizen in
> > terms
> >   of operating systems we support. While PHP on Windows may not
> > have the
> >   speed that the Unix counterpart have, it is still a very
> important
> >   development platform. Many developers develop on Windows and
> > deploy on
> >   a Unix based system, being unable to test such an important
> > feature in
> >   a development environment is also a large question mark.
> >  >>>
> >  >>> As long as we can agree that very few actually *deploy *on
> > Windows, I
> >  >>> think
> >  >>> we're on solid grounds.
> >  >>> As the JIT implementation is likely to have at least *some*
> > significant
> >  >>> differences compared to Linux, I'm not sure what testing it on
> > Windows
> >  >>> would give you.  JIT is supposed to be entirely transparent,
> > and the
> >  >>> performance characteristics - as well as the bug patterns - are
> > likely to
> >  >>> be quite different on Linux vs. Windows, at least in many cases.
> >  >>> Is it really that important to have?
> >  >>>
> >  >>> I'm honestly a bit perplexed by how many people here viewing
> > Windows
> >  >>> support as a must have, while at the same time I think we all
> > agree PHP is
> >  >>> very scarcely found on production Windows servers, and JIT is a
> >  >>> predominantly production feature.
> >  >>>
> >  >>> I'm personally interested in taking a look at it (and I'm
> certain
> >  >>>
> >   Anatol does too), but simply dismissing is a no-go for me.
> >  >>>
> >  >>> It'd be interesting to evaluate the cost associated with
> supporting
> >  >>> Windows.  Bare in mind, we're proposing to vote on this as a
> > production
> >  >>> feature for PHP 8 - which realistically means almost two years
> > from now
> >  >>> *at
> >  >>> the earliest*.  I'm sure we'd have Windows support a lot sooner
> > than that
> >  >>> if we decide that it's a must have.  I agree with Nikita that
> > the key
> >  >>> question is in fact, do we or do we not want to introduce JIT
> > in - with
> >  >>> the
> >  >>> main question being the maintenance cost.  Let's tackle this
> > question
> >  >>> first, otherwise - why send Dmitry (and maybe others) 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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.
> 
> As others have said:
> 
>    I don't like the idea of omitting to support windows, less worried 
> about fancy architectures.

I can provide help to people who will going to implement JIT support for 
Windows. This is not going to be easy, because MSVC doesn't support 
"hybrid VM" and "global register variables", therefore the code is going 
to be more expensive.

>    I'm not keen on the idea that there is no way to debug the code this 
> generates outside of GDB, and I'm not sure how useful gdb will be: I've 
> tried to debug JIT'd code in that before and it doesn't do so well, but 
> I could easily have been doing it wrong. I'd be very happy to be 
> corrected about this ?

I'm not sure, what is wrong with GDB, and if any other debuggers have 
special API for run-time generated code.

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

Thanks. Dmitry.

> 
> Bottom line though, I love it, it's brilliant, and look forward to PHP 8.
> 
> Thank you, Dmitry.
> 
> Cheers
> Joe
> 
> 
> On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  > wrote:
> 
> 
> 
> 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
> mailto:ka...@php.net>>
>  >>>
>  >>> wrote:
>   Without my usual Windows bias, I do believe it is a
> considerable fact
>   like Nikita pointed out as Windows is a first class citizen in
> terms
>   of operating systems we support. While PHP on Windows may not
> have the
>   speed that the Unix counterpart have, it is still a very important
>   development platform. Many developers develop on Windows and
> deploy on
>   a Unix based system, being unable to test such an important
> feature in
>   a development environment is also a large question mark.
>  >>>
>  >>> As long as we can agree that very few actually *deploy *on
> Windows, I
>  >>> think
>  >>> we're on solid grounds.
>  >>> As the JIT implementation is likely to have at least *some*
> significant
>  >>> differences compared to Linux, I'm not sure what testing it on
> Windows
>  >>> would give you.  JIT is supposed to be entirely transparent,
> and the
>  >>> performance characteristics - as well as the bug patterns - are
> likely to
>  >>> be quite different on Linux vs. Windows, at least in many cases.
>  >>> Is it really that important to have?
>  >>>
>  >>> I'm honestly a bit perplexed by how many people here viewing
> Windows
>  >>> support as a must have, while at the same time I think we all
> agree PHP is
>  >>> very scarcely found on production Windows servers, and JIT is a
>  >>> predominantly production feature.
>  >>>
>  >>> I'm personally interested in taking a look at it (and I'm certain
>  >>>
>   Anatol does too), but simply dismissing is a no-go for me.
>  >>>
>  >>> It'd be interesting to evaluate the cost associated with supporting
>  >>> Windows.  Bare in mind, we're proposing to vote on this as a
> production
>  >>> feature for PHP 8 - which realistically means almost two years
> from now
>  >>> *at
>  >>> the earliest*.  I'm sure we'd have Windows support a lot sooner
> than that
>  >>> if we decide that it's a must have.  I agree with Nikita that
> the key
>  >>> question is in fact, do we or do we not want to introduce JIT
> in - with
>  >>> the
>  >>> main question being the maintenance cost.  Let's tackle this
> question
>  >>> first, otherwise - why send Dmitry (and maybe others) for doing
> more work
>  >>> (Windows support) if we are likely to flush it all down the toilet?
>  >>>
>  >> Maybe we're the only ones, but we run production PHP on Windows.
> I have no
>  >> issues with the idea of not initially having support for
> Windows. I can
>  >> probably even live with never having support for Windows -
> provided that we
>  >> don't find ourselves in a situation like Nikita mentioned where
> features
>  >> start getting developed in PHP instead of C and require JIT in
> order to
>  >> function.
>  >
>  > Question from a non-compiler-engineer: Could we end up in a
> situation where
>  > future language features (in 8.3 or 

Re: [PHP-DEV] Remove zpp variation tests

[Nikita Popov]

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
> zpp
> > and the behavior is always going to be the same.
>
> This is true for functions that use standard zpp handling, but there are
> a number of them that use custom zpp handling, and for those there could
> be corner cases which aren't handled properly. In fact, I've seen some
> zpp-using functions that so not properly handle nulls, empty strings,
> etc. as arguments (zpp works fine, it's the part past zpp that fails).
> So we need to be careful and remove only those tests that are indeed
> handled by zpp and not the code beyond it that does need to be tested,
> and not remove tests which cover custom argument handling.
>

Yes, we shouldn't remove tests for custom argument handling. I've started
working on this in https://github.com/php/php-src/pull/3783 and try to
check for all tests whether this is a simple zpp argument or not. I'm also
switching some cases to use zpp on the PHP 8 branch, where functions had
some custom argument handling for no good reason.

Nikita

Re: [PHP-DEV] [RFC] JIT

[Larry Garfield]

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 know there were some RFCs rejected in the past on
> > the
> > grounds that they involved too many runtime checks (and thus a performance
> > hit); if it were possible for a JIT to optimize some of those away, it
> > might make the cost acceptable.  However, if a JIT only works on some
> > systems that might widen the gap between have- and have-not platforms.
> 
> I think, JIT only approach doesn't make a lot of sense for PHP, with one
> of the most fast VM. And this is a trend. Even V8, starting from JIT
> only, switched back to VM+JIT.
> 
> Thanks. Dmitry.

I'm... not sure how that answers my question?  I'm saying "if we had a VM+JIT, 
and the JIT part made feature X acceptably fast but it wasn't acceptably fast 
with just the VM, is that a problem?"  Or is that a situation that cannot 
happen?  Or that we don't care if it happens?

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

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

[Larry Garfield]

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
> > 
> > points here:
> > > Reasoning: If somebody is out of the project for 10 years they probably
> > > lost track on how the language and needs evolved and just voting since
> > > an old friend needed a deciding vote is bad.
> > 
> > I agree, though "out of project" can differ... But I think if the person
> > had made no contribution for a decade, then probably he wouldn't be very
> > well informed voter. Easier way would be to make the list of such people
> > and let them ask on the list that their vote will be kept if they want
> > to, with explanation on how they plan to continue contribute (we don't
> > have to require actual contribution, just people promising to do so - we
> > are all volunteers here anyway). People that have long moved on would
> > just ignore that, and people who want to come back will do so.
> > 
> > > For groups like FIG I am uncertain. I think it is a good thing if we
> > > push more things out of PHP itself into the userspace (JIT, FFI, ...
> > > allow more and more stuff to be done in userspace) and thus
> > > coordinating with userspace developers and setting standards and
> > > interoperability there is good. However it are the maintainers who
> > > (often voluntarily) have to maintain these things and overruling actual
> > > maintainers is bad as they lose interest.
> > 
> > Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having
> > input from major userspace groups is great. But having input and having
> > deciding voice is a different thing. Discussion and vote are different
> > processes, both important but with different results. So I wonder if we
> > can't find some venue to collect this feedback without having people who
> > aren't core developers decide for core developers what should they do.
> > This sounds like something that won't be healthy.
> > --
> > Stas Malyshev
> > smalys...@gmail.com
> > 
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 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 adding 51 new voters, all from the
> same external organization (one that has been aggressively gunning for
> "official" recognition since its inception).  In other words, this RFC, in
> its current form, would have effectively handed control over the entire PHP
> project to FIG.  Though I'm sure it was never the intent, TBH, this does
> feel like a bit of a slap in the face to past contributors who still have
> good ideas to offer now and then and should still have a voice.
> Furthermore, it seems strange to me that a provision with such massive and
> far-reaching implications would be quietly buried at the bottom of an RFC
> filled with otherwise popular, non-controversial ideas.

Two points here:

1) Please see my earlier message.  The way FIG is structured, one could extend 
voting rights to project representatives, the core committee, both, or 
neither.  The core committee is 12 people.  Project reps are ~36 currently.  
Adding 12 people to the voting pool would not "effectively hand control over 
the entire PHP project to FIG".  That's complete hyperbole.  Even if it were 
all 50 people, that's still less than a third the number of people that would 
currently pass Zeev's proposed filter for direct contributors.  It may be too 
large an external constituency, but it's a long, long way from a controlling 
majority.

2) To say that FIG "has been aggressively gunning for "official" recognition 
since its inception" is false.  The "PHP Standards Group" that originally 
self-formed in 2009, yes, presumed a lot more official status than it was due, 
and was (rightly) thrown off of the php.net infrastructure as a result.  That 
was a decade ago and FIG today is a very different organization.  It does not 
claim any authority or official-ness beyond "a lot of people listen to our 
recommendations", which is objectively true.

Using FIG as a proxy for community voters may or may not make sense in the 
long run, but please do not misrepresent either FIG or Zeev's proposal.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

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

[Midori Koçak]

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 versions may have unpatched security holes, and
> encouraging users to keep using them is a disfavour to the community IMO,
> which can only delay adoption of newer versions, and lead to an even more
> painful upgrade path when you have to upgrade N versions at once. My stance
> on this is that projects written in PHP have to evolve together with the
> language, and I'm personally not surprised to have to rewrite a few things
> whenever a major PHP version is released (and I do maintain quite a number
> of projects). Let me rephrase this: actually, I would be HAPPY to rewrite
> my projects towards a more consistent PHP language.
>
> That being said, I know this opinion is a minority on this list, so let's
> put it aside for a moment.
>
> Now what prevents PHP from adding consistent function names / APIs, and
> deprecating the older ones? We can keep the old ones for 10 more years if
> you wish, but at least new PHP code can start using the "correct" ones, and
> progressively the share of PHP code out there using the old ones should
> progressively get lower over the years, up to the point where we could
> eventually decide that it's not worth keeping them. The thing is, if you
> never start, the situation will never improve.
>
> You know the proverb: The best time to plant a tree was 20 years ago. The
> second best time is now.
>
> Ben
>
> On Thu, 31 Jan 2019 at 11:30, 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 becoming some sort of
> > > stubborn belief and less and less people want to fix it.
> > >
> > > The RFC: Consistent function names [1] shows the magnitude of this. I
> > > don't think every function listed there needs a change so it can be
> > > greatly reduced. But still this can be done in several years to 10
> > > years or so (measuring over the thumb).
> > >
> >
> >
> > Hi,
> >
> > I'm sorry if I sound stubborn, but I have yet to see a reasonable answer
> to
> > the fundamental problem: the effort needed is not on the part of a few
> > volunteers changing the language, it is effort by *every single user of
> the
> > language*, rewriting *every single PHP program ever written*.
> >
> > WordPress officially supports both PHP 5.2, released 13 years ago, and
> PHP
> > 7.3, released a couple of months ago; one of their biggest challenges in
> > raising that bar is that they, too, have to persuade a community (the
> theme
> > and plugin authors) to change their code to match. That should give you
> > some idea of how long old and new names would have to exist side by side,
> > while we waited for everyone to rewrite all their code, and meanwhile,
> the
> > language would be *even more inconsistent*, because there would be extra
> > ways of writing the same thing.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
>

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

[Jan Schneider]

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] extension.

Pierre is listed as maintainer. But given that he is for deprecating it,
I guess we try to find somebody who is willing to revive it (not likely)
and failing that (likely) go the deprecation route probably... Given how
many references to it I see on github though, it's not the best outcome.



I'd like to take this one, too.

RoundCube may roll its own, but I know the popular Horde IMP uses this
extensively.


Horde isn't using ext/imap since ages, but has developed a PHP-only  
IMAP library long ago, that's being used by many other OSS projects too.



I suspect that the extension's going to have the performance
one would desire when dealing with giant mailboxes, but c-client is hard to
deal with. I've had experience with c-client for a while (stretching back
to Pine days), and yet still would like to roadmap our way to a modern
implementation.

bishop




--
Jan Schneider
The Horde Project
https://www.horde.org/


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

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

[Paul Jones]

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 is a very different organization.  It does not 
> claim any authority or official-ness beyond "a lot of people listen to our 
> recommendations", which is objectively true.

Larry is trying to play both sides here with plausible deniability. Quoting him 
from https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/ :

> FIG has effectively become the standards body for PHP. It took time for it to 
> earn it, but it did, thanks to the work of dozens of people, both FIG members 
> and not. A [Reddit 
> thread](https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/)
>  started last January showed that, while not universal, there was a clear 
> preference for FIG to step up and accept that role formally.

Either Larry feels that FIG is effectively a standards body, or he does not.

And now that I have spoken, I may be more to say on the matter -- but not just 
yet.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




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

Re: [PHP-DEV] [RFC] JIT

[Rowan Collins]

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 intended audience for an
experimental JIT in 7.4. Presumably, it would be marked as not suitable for
production, so would only be of interest to those experimenting with the
feature; but any problems they find might already be fixed in master, so
would it be better to encourage them to download a snapshot build of
8.0-pre-alpha and test there?

Regards,
-- 
Rowan Collins
[IMSoP]

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

[Dan Ackroyd]

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 to solve
by changing the rules about who can vote.

Without presenting the problem, and why your solution is the correct
one, it's not obvious that the change being proposed is either needed
or the right one choice.

Additionally, giving a vote to members of PHP-Fig is not a good idea
for multiple reasons.

* They are not language designers and they do not know PHP internals.
They cannot evaluate the tradeoffs of changes.
* The membership requirements of the FIG were 'gamed' by some projects
by using bots to create fake stars on Github and number of downloads
to meet the requirements for FIG membership.
* Other members such as Symfony, Laravel and Doctine have left FIG.

btw, you seem to have completely overlooked extension maintainers from
your list of people who should have a vote on PHP internals.

cheers
Dan
Ack

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

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

[Bishop Bettini]

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 ext/imap as soon as possible, since
> >> > this is not the only issue[5] of this unmaintained[6] extension.
> >>
> >> Pierre is listed as maintainer. But given that he is for deprecating it,
> >> I guess we try to find somebody who is willing to revive it (not likely)
> >> and failing that (likely) go the deprecation route probably... Given how
> >> many references to it I see on github though, it's not the best outcome.
> >>
> >
> > I'd like to take this one, too.
> >
> > RoundCube may roll its own, but I know the popular Horde IMP uses this
> > extensively.
>
> Horde isn't using ext/imap since ages, but has developed a PHP-only
> IMAP library long ago, that's being used by many other OSS projects too.
>

I appreciate the clarification, Jan, thanks. I must have been reading the
h3 docs, instead of current. o.O

The library is indeed very nice, https://github.com/horde/Imap_Client/
Looks like it's faster than native ext/imap, too
https://dev.horde.org/imap_client/
One recent SO answer comparing ext/imap and Horde Imap_Client:
https://stackoverflow.com/q/6659409/2908724

Given the high quality userland option(s) out there, it seems a waste of
effort to revitalize the extension with a fresh imap implementation. We
should be fixing the bugs though, and I'll focus on that. For now let's
just call it actively maintained, but feature frozen?

bishop

Re: [PHP-DEV] [RFC] JIT

[Levi Morrison]

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 PHP-8, where we are
> > going to continue active improvement, and into PHP-7.4, as an experimental
> > feature.
> >
> >
> > Thanks. Dmitry.
> >
>
> This has been a long time on the horizon, nice to see this finally moving
> forward :)
>
> Here are some initial thoughts: I think that it's best to approach this
> issue from a cost/benefit angle. The benefits of the JIT compiler are
> roughly (and as already outlined in the RFC):
>
>  * Significantly better performance for numerical code.
>  * Slightly better performance for "typical" PHP web application code.
>  * The potential to move more code from C to PHP, because PHP will now be
> sufficiently fast.
>
> However, there are also a number of costs, on which I'll expand in more
> detail:
>
> a) Maintenance: This is really my main concern. Right now there are about
> 3-4 people who I would trust to carry out a non-trivial language change,
> which will require touching the compiler, the virtual machine, the
> optimizer and the persistence layer. Each of those components is quite
> complex, in different ways. Some people who are comfortable with doing VM
> changes will struggle with implementing optimizer changes.
>
> Adding a JIT compiler exacerbates this issue further. Because this JIT is
> dynasm based, the core JIT code is essentially written in raw x86 assembly.
> This will further limit the pool of people who will be able to make
> non-trivial engine changes. Personally, I don't have any particular
> familiarity with writing x86 assembly, so it will likely take a while to
> get up to speed with this code.
>
> b) Bugs and stability: I think that everyone is aware that the initial PHP
> 7.3 release suffered from substantial stability issues, more than new minor
> version releases tend to do. I think there are multiple reasons for that
> (and we might want to start a conversation about our QA processes in a
> separate thread), but one main contributing factor were opcache optimizer
> bugs. Compiler optimizations are tricky and hard to verify, and we often
> only learn about issues once the optimizer makes contact with production
> codebases, which feature a much richer collection of code patterns than our
> test suite. One can wonder whether the relatively minor speedups we get
> from our optimization framework are really worth having these stability
> issues...
>
> Adding a JIT compiler adds a new dimension of stability issues. Next to
> "simple" executor bugs, and optimizer bugs, we now get additional bugs in
> the JIT. These are probably going to be hard to debug, as we'll have to
> drop down from our usual C-level tooling, down to inspecting assembly.
>
> c) Platform support: Having a JIT segregates platforms into two tiers:
> Those that have JIT support and those that don't. While that is not a
> problem per se, it does introduce some dangers. For example, if we decide
> to more parts of our C code into PHP because PHP is fast enough with a JIT,
> that will of course only be true for platforms that actually have JIT
> support. I'm not terribly concerned about loosing out some performance on
> MIPS, but we do need to make sure that all our main platforms are supported
> (Windows is a must there, imho).
>
> d) Debugging: I'm not sure whether or not this is an issue (maybe the RFC
> can clarify?), but I'm wondering if this will have an impact on things like
> XDebug. Will it be possible to using XDebug to accurately inspect variables
> at any point in time while the JIT is running? If not, that would be a big
> tooling regression.
>
> I think those are the main points that come to mind right now...
>
> Regards,
> Nikita

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. As
such, I consider this dead on arrival, even if it's considered
experimental. There are cross-platform JIT's out there -- how do they
manage it? I think that's the next critical step.

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

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

[Mark Baker]

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 more insight into the 
internals of PHP than the average PHP developer, but sit astride the 
fence between the core an duserland development


-- 
Mark Baker

  _
|.  \ \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

  I LOVE PHP


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

Re: [PHP-DEV] [RFC] JIT

[Pierre Joye]

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 or simply lack of time to test on
MSVC.  LibJit and DynAsm support it

As
> such, I consider this dead on arrival, even if it's considered
> experimental. There are cross-platform JIT's out there -- how do they
> manage it? I think that's the next critical step.
>

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

[Pedro Magalhães]

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 pass with a slim majority seems a wasted effort to me. As "proven" by
the currently open issues, it also misses a categorization for
administrative changes. Stating only which changes require a RFC and which
don't would be much simpler. Also, that last part about performance
degradation will also lead to unnecessary discussion if it isn't more
clearly defined (is it just the bench.php? mediawiki test suite?).

On the section about Changing the RFC, again a distinction is made between
extending the period for 1 or 2 weeks depending on what you subjectively
consider "substantial". For the sake of simplicity, I'd suggest it to be
always 1 week.

About No Discussion/Voting Periods, I think it would be simpler to just
extend the voting period to a minimum of 2 weeks. For anyone interested on
the subject, they would have 4 weeks to find out about it (2 for discussion
and 2 for voting). Maybe some people actually have more time to
contribute/participate in discussion during their holidays.

As stated before, The Eligible Voters section fails to mention its reason
to be. Lately, RFCs get around 20 to 40 votes, why do we have to reduce the
list of potential voters? To me, it seems arbitrarily hostile to newcomers
while overly protective of people that have long lost interest. In other
words, someone who has made their last contribution 10 years ago keeps
their vote while someone who fixed a bug every 2 weeks for the last year
isn't eligible. Also, the proposed measurements are subject to be "gamed"
(not squashing your commits, changes to license headers, etc..). And for
other members of the project the same problem poses, how do you measure
docs contributions? And maintaining the servers? And PECL extension
maintainers?
About FIG, it is an organization which has its own membership rules that
are subject to change at any time at its own discretion. While I truly
believe that it would be very important to provide a way to allow the users
to express their voice, doing that via an external organization doesn't
seem acceptable. Keep in mind that the current voting RFC keeps the
decision of which community members can vote in PHP's side.
To cater to an even larger audience, there could be a section on RFCs where
anyone could cast their vote so that the RFC author can also take it into
consideration but keeping it non-binding. (Or perhaps giving it a
predefined weight - 1, 3, 5 votes?)

Regards,
Pedro

On Thu, Jan 31, 2019 at 1:44 PM 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:
>
>
>
> https://wiki.php.net/rfc/voting2019
>
>
>
> Emphasis on ‘attempting’.  I’m sure there are still a lot of holes in it
> that should be plugged before we vote on it, but instead of waiting
> indefinitely – I’d like us to start discussing it.
>
>
>
> Comments and suggestions welcome.
>
>
>
> Zeev
>
>
>
>
>
>

Re: [PHP-DEV] Disable PEAR by default

[Peter Kokot]

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: https://github.com/php/php-src/pull/3781
> >
> > +1

Thank you Nikita for the pull request for this. With all the respect
to PEAR project and people behind it, maybe the PEAR itself should be
added to some sort of recognition page in the manual for their
involvement and work on the first installer of PHP code and initial
move into code reuse, open source PHP libraries, and all that. As time
went forward, Composer took over the role of such installer in PHP
community. One of the most problematic issues and a reason for the
following questions is that I haven't noticed there has been any major
involvement in the past few years or some roadmap created for PEAR
(I'm not talking about PEAR packages here, only the PEAR core script).
Code itself is legacy and needs almost a complete rewrite. Omitting
things like PSR-4 makes coding with it very legacy, that's why it is
not recommended anymore. Why is PEAR even part of the php-src? From my
understanding, that is because of only one element/script. That is
pecl script. For everything else it can be downloaded separately, as
is Composer and all other tools needed for the usual daily workflow
with PHP.

So,

Q1: Shouldn't be a much better approach here to deprecate this
installation option in PHP 7.4 and remove it completely in PHP 8?

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?

With only disabling installation option, nothing major is done
actually, I think but if there is some other plan here that +1 I
guess.

-- 
Peter Kokot

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

Re: [PHP-DEV] Disable PEAR by default

[Alice Wonder]

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 is disabled by 
default

in

PHP 7.4. PR: https://github.com/php/php-src/pull/3781


+1


Thank you Nikita for the pull request for this. With all the respect
to PEAR project and people behind it, maybe the PEAR itself should be
added to some sort of recognition page in the manual for their
involvement and work on the first installer of PHP code and initial
move into code reuse, open source PHP libraries, and all that. As time
went forward, Composer took over the role of such installer in PHP
community.


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 that is what 
composer provides.


And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.



"because that is what composer provides." should be "because that is 
what composer specifies."


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

Re: [PHP-DEV] Disable PEAR by default

[Peter Kokot]

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 that is what
> composer provides.
>
> And it can be the dependency of a dependency of a dependency.
>
> I do not like Composer.
>
> Adding a "recognition page" while cutting PEAR off also seems, well, slimy.

Frankly, this is irrelevant. If you don't use Composer, that's your
choice. PEAR isn't maintained and will cause similar issues all the
time. Not removing this installation option from php-src in the near
future means maintaining patches for all that time this option will be
present in the PHP and shipping separate pear package for all Linux
distributions. I don't like the sound of that.


-- 
Peter Kokot

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

Re: [PHP-DEV] Disable PEAR by default

[Peter Kokot]

> 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 level (per project)
is much more scalable and overall better, but whatever works for your
project.

> Composer is like static linking compared to PEAR which is liked shared
> linking.

Composer can install things globally. I'm not sure I understand why is
this even a discussion Composer vs. PEAR core installer script at the
moment. The pull request is about disabling the PEAR option. Which I
suggest to go further because, for example, waiting for a PHP 10
release for this step is really not a smart move for multitude of
reasons...

> So what problem is this really solving?

Every PEAR issue actually that was caused in the several years. This
time it was the each(), next version will be foo()... Not to mention
that still there are bugs out there that are really painful to solve.
For example, shared core (shipped) PHP extensions and PEAR is a no go
without a patch. I mean if there are maintainers, and people who want
to keep this PEAR in the php-src repository, fine I guess. But then
I'm not sure what can be done here anyway...

-- 
Peter Kokot

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

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

[Bishop Bettini]

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 member, but caucuses as a core developer.
>
> How do you define "top 13 committers"? How do you prevent people from
> playing the system by committing typo changes in comments etc.? Will
> somebody who rewrites a larger change into a single commit be
> negatively ranked compared to somebody who creates a small fix which
> requires multiple small fixes afterwards?


> I don't think quantity of anything (lines changed, commits, ..) is a
> good metric in any way.


> Either the list of contributors has to be inclusive or people have to
> be elected (with all the issues of electing people)
>

TL;DR: I don't think it matters. Any quantitative measure identifying those
with the highest skill, accomplishment, availability, and belief in the
community will suffice. The combined effect of a multi-cameral system,
quorum, and super-majority override will minimize the effects of gaming.

Identifying those who can vote requires a "selection metric". Our current
unicameral voting system has a "low bar" selection metric. The voting
eligibility portion of Zeev's proposal changes the selection metric, but
keeps the unicameral body. I feel formally identifying the top contributors
and giving them a separate say is an important step toward reform, but
retaining a unicameral body is not, in my opinion, progress.

So, how do we identify those who are currently the most contributory?
Commits mostly, though we can't ignore other qualities. In a 2003 paper
[1], Scacchi (UC Irvine) defined a F/OSS meritocracy pyramid in which those
at the top had the highest *perceived* authority. Kaats (Utrecht
University) et. al. in 2014 [2] built on Scacchi's research saying:

"In order to assess the merits [of those at the pyramid top] one
cannot simply measure one aspect... while most had a good commit
track-record, there were also a fair amount that had barely written any
code... yet those individuals might contribute in other ways."

Scacchi's research cautions, in counterpoint, that SCM write access is a
form of potentially damaging control:

"The ability for the eyes of many developers to review or look over source
code, system build and preliminary test results, and response to bug
reports also realizes peer review and the potential for embarrassment as a
form of indirect social control over the timely actions of contributing
F/OSS developers. Thus, F/OSS development allows for ... manipulation by
the core developers, so as to encourage certain patterns of software
development and social control, and to discourage others that may not
advance the collective needs"

That is, git is a mechanism for control. Be that gaming to enter the
selection metric, or by rejecting contributions of others, it's a means for
those who *can* contribute to control those who only *might* contribute.

So while a selection metric based on commits is a robust means of
identifying top contributors, it's necessary - but not sufficient - and may
even be damaging. For this reason I suggest the safer strategy of a
multi-cameral system that includes the voices of those who don't commit, or
commit substantially less than those selected as top.

Let us imagine a faction that games git and seizes majority control over
the core contributors metric. Under Zeev's voting eligibility proposal, yes
it'd be harder to game the contingency of 175 members. But, that large a
group also can't reasonably form a quorum, which means we have no assurance
those that vote speak for the group. Under my counter-proposal, with only 7
members to quorum, it's statistically easier to game. But those that are
bumped out still have a vote in the community, so the effect of gaming is
effectively cancelled. Further, the community does not have to form a
quorum, so it's statistically easier for the community to counter a 2/3
super-majority of core developers. Which is why, in all likelihood, the
tie-breaking member would typically be a top committer or a grand-elder.

In short, the balance from a multi-cameral system limits the effects of
gaming git and gives a vote to those who contribute in ways other than
writing huge amounts of code.

[1]:
https://www.researchgate.net/publication/21660_The_Merits_of_a_Meritocracy_in_Open_Source_Software_Ecosystems
[2]:
https://www.researchgate.net/publication/2856601_FreeOpen_Source_Software_Development_Practices_in_the_Computer_Game_Community

Re: [PHP-DEV] Disable PEAR by default

[CHU Zhaowei]

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.
 
 
-- Original --
From:  "Alice Wonder";
Date:  Sat, Feb 2, 2019 09:08 AM
To:  "internals"; 

Subject:  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: https://github.com/php/php-src/pull/3781
>>>
>>> +1
> 
> Thank you Nikita for the pull request for this. With all the respect
> to PEAR project and people behind it, maybe the PEAR itself should be
> added to some sort of recognition page in the manual for their
> involvement and work on the first installer of PHP code and initial
> move into code reuse, open source PHP libraries, and all that. As time
> went forward, Composer took over the role of such installer in PHP
> community.

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 that is what 
composer provides.

And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.

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

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

[Johannes Schlüter]

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 committers"? How do you prevent people from
playing the system by committing typo changes in comments etc.? Will
somebody who rewrites a larger change into a single commit be
negatively ranked compared to somebody who creates a small fix which
requires multiple small fixes afterwards?

I don't think quantity of anything (lines changed, commits, ..) is a
good metric in any way.

Either the list of contributors has to be inclusive or people have to
be elected (with all the issues of electing people)

johanes

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

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

[Kalle Sommer Nielsen]

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 coders.  Currently, in order to vote
> (have a direct impact) you need to be a C developer; you technically don't
> need to even know how to write PHP, just C. :-)  That's a very different
> mindset and perspective than people who write PHP all day, and both are
> valuable.  The PHP community is much, much larger than the PHP Internals C
> developer community.
>
> At the same time, I fully agree with Kalle and Johannes that it would be a
> very bad idea for the Internals/C developers to be "forced" to maintain
> something they think is a bad feature because the great unwashed masses (who
> by nature don't realize just how terrible an idea is for the parser, for
> instance) thought it was cool and trendy.  Yet the fact that the unwashed
> masses think something is useful is relevant and a point that should be
> considered.
>
>  So I would support a mechanism of some sort to give formal voting rights to
> non-internals-C-developers who are still significant-PHP-contributors, as long
> as the number of people involved is relatively low compared to the direct-
> contributor number.  With a contributor voting pool of ~175 (which would no
> doubt vary but let's assume stays in vaguely the same range), an "at large
> voter" population of 5, 10, or 15 people would provide direct representation
> without a meaningful risk of swamping the direct contributors, who I agree
> should remain the overwhelming majority of eligible voters.

So while you fully agree with its a bad idea that us the Core
Developers have to maintain code that is decided by external, non
contributing parties, still you think there should be a way for non
Core Developers to vote? That is kinda absurd.

> Whether FIG is the best way to select that community-voter constituency I'm
> not sure.  Or rather... I don't see any alternative mechanism that wouldn't
> involve, essentially, replicating the work FIG has done to determine
> appropriate "leading members of the community at large".  So if tapping FIG
> isn't the preferred way, the alternative would involve, essentially,
> duplicating at least a large part of FIG's process.

Any project that would like a say in something related to PHP as a
language, should, much like yourself, contribute to discussions. We as
developers do listen to feedback and take that into account when
designing and implementing features for the language, as it is
naturally made for our users, we value that input a lot and I use that
often as a determining factor to whether or not I vote yes to an RFC,
and I'm certain that I'm not the only one that puts personal bias a
little to the side in that scenario.

> This would be the first formal recognition of FIG by PHP Internals.  I am
> completely OK with that, and personally would love to see Internals and FIG
> collaborate more; I'm just noting it for completeness.

I'm not okay with that at all. I accept and respect what you as a
project do, but because of that it doesn't mean you (you as in a
project) should have a special right over our project because you
represent some of the most used userland projects. Besides the very
high profile projects like Laravel and Symfony (even projects like
Doctrine and Guzzle) is no longer represented, WordPress is not even a
part of the FIG.

The moment we as The PHP Project collaborate with you as the FIG, it
means that we will be seen as promoting FIG, and therefore it means
there is a certain favoritism towards picking what the FIG does
because the PHP project collaborates with them, essentially not
allowing competing projects or initiatives to have a space there, or
it would mean we also would have to take them aboard etc. That is a
mess and something we should avoid and why we do not use others
packages and projects for building our own web infrastructure. We need
to be neutral and transparent as a project because of the scale that
is PHP.

> Another point there is that the RFC doesn't specify what "member of FIG"
> means.  FIG currently has 3 defined groups of people: Secretaries (3 people),
> the Core Committee (12 people), and Project Representatives (36 people at
> Zeev, which group is intended?
>
> To provide some insight (with a little over-simplification):
>
> * Project Representatives are appointed by their respective projects, and are
> usually but not always project leads.  The bar for membership is extremely
> low, by design, and most in practice most project representatives are inactive
> 99.99% of the time.
>
> * The Core Committee is elected by Project Representatives, and are at least
> moderately active, much of the time.  They're responsible for reviewing,
> tracking, and approving PSR proposals, and are supposed to be active
> 

Re: [PHP-DEV] Disable PEAR by default

[Alice Wonder]

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: https://github.com/php/php-src/pull/3781


+1


Thank you Nikita for the pull request for this. With all the respect
to PEAR project and people behind it, maybe the PEAR itself should be
added to some sort of recognition page in the manual for their
involvement and work on the first installer of PHP code and initial
move into code reuse, open source PHP libraries, and all that. As time
went forward, Composer took over the role of such installer in PHP
community.


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 that is what 
composer provides.


And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.

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

Re: [PHP-DEV] Disable PEAR by default

[Alice Wonder]

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 in the older version because that is what
composer provides.

And it can be the dependency of a dependency of a dependency.

I do not like Composer.

Adding a "recognition page" while cutting PEAR off also seems, well, slimy.


Frankly, this is irrelevant. If you don't use Composer, that's your
choice. PEAR isn't maintained and will cause similar issues all the
time. Not removing this installation option from php-src in the near
future means maintaining patches for all that time this option will be
present in the PHP and shipping separate pear package for all Linux
distributions. I don't like the sound of that.




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.


Composer is like static linking compared to PEAR which is liked shared 
linking.


Yes it's my opinion, it just seems that deprecating it is a reactionary 
decision caused by the current unfortunate situation, but there's no 
reason why Composer will not also have the same issue as the current 
situation. All it takes is hijacking a github account and trojan updates 
are easy to push through composer.


So what problem is this really solving?

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

Re: [PHP-DEV] Disable PEAR by default

[Rowan Collins]

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 of Pickle: 
https://github.com/FriendsOfPHP/pickle

As far as I know, the effort stalled only for lack of human resources to get it 
stable, not because of any fundamental blockers, so if someone took it in, it 
could probably happen.

Regards,

-- 
Rowan Collins
[IMSoP]

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