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

[Stanislav Malyshev]

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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Morning Stas, and all,

This discussion was ... a mess, partly my fault, I suppose.

I said I was going to bring it up for voting quickly on the say so of
Nikita, and because it feels urgent to us, you can guess our reasons for
that.

I'm not going to argue back and forth for the next week about the reasons
we think this is important.

In a week, let's say next Friday, to be totally fair, this RFC will go to
vote.

Cheers
Joe

On Fri, 1 Feb 2019 at 06:16, 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.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Stanislav Malyshev]

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.

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

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

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

[Larry Garfield]

On Thursday, January 31, 2019 12:17:02 PM CST Chase Peeler wrote:
> On Thu, Jan 31, 2019 at 11:52 AM Zeev Suraski  wrote:
> > On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen 
> > 
> > wrote:
> > > Hi Zeev
> > > 
> > > Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> > > > 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
> > > 
> > > I wholeheartedly disagree with the PHP-FIG special exception to who
> > > can vote, call me biased but I do not believe it serves any purpose
> > > and is absurd. People who actively work on PHP, should be the ones to
> > > be able to have a choice, I think that should be reserved for any
> > > contributor who puts effort working on PHP.
> > > 
> > > I do understand that we are the language and our work affects the
> > > others the most. However making special exceptions for who can vote
> > > and essentially having a say from an external source in what I in
> > > theory need to help maintain as a PHP Core Developer is terrible. Why
> > > not allow WordPress Core Developers to have a say instead, as their
> > > work has a larger impact on the usage of PHP? (That was obviously a
> > > bit of sarcasm, the last part). We are not allowed to vote at their
> > > individual projects features (nor do we need to have a say if we are
> > > not actively involved in the development of said projects or
> > > organizations) and I stand very strongly behind that belief.
> > 
> > That's a very fair point.  I'm personally undecided on this.  It's fair to
> > say that in 2011, my thinking was that voting rights should be given
> > pretty
> > much exclusively to contributors.  It may sound like overreaching, but the
> > reality is that this is pretty much how ALL open source projects work (and
> > have been working).  The reason it sounds overreaching, is that over the
> > several years following the ratification of the 2011 Voting RFC - a status
> > quo of "virtually anybody can vote" took hold, and it's now fairly
> > entrenched in people's minds.  It's still very, very awkward when taken in
> > the context of how OS projects behave in general.
> > The thinking behind PHP-FIG (and for that matter, having some
> > representation from WordPress, yes, I'm not kidding...) was to create
> > something which goes a bit farther than what's usual in an OS project -
> > because of the status quo we have today.  Making it a bit easier to
> > digest.  But it may be that it's the wrong approach.  I'll be interested
> > to
> > see what others think about it as well.  I'm personally open both for
> > extending that list further - or potentially trimming it down - making it
> > more of a meritocracy, as is customary in virtually all other OS projects.
> > 
> > I don't know if there is a good way to implement it, but I definitely
> 
> think there is value in some sort of voice being given to those that use
> PHP to build things, but don't contribute to the actual source.
> 
> I think it's important, though, to make sure that developers that are out
> there actually developing things with PHP (not to say that contributors
> don't belong to that group) have a voice - I'm just wondering if that needs
> to be defined in a more formal way. One statistic I just found says that
> almost 6 million websites are running PHP7. Even if we assume that it
> averages out to where there is 1 developer for every 100 sites, that's
> still 60,000 developers being represented by 175 voters.
> 
> Maybe the voice that we currently have in the form of being able to
> participate in these discussions is enough. I'd be interested in knowing
> how often voters are persuaded to take a position on an issue after
> discussing it with non-voting developers - whether via these discussion
> lists or on other mediums.
> 
> Maybe instead of giving all members of PHP-FIG a vote, the RFC can be
> amended to specify that PHP related groups with a certain number of active
> members are given a single vote. Or, instead of membership numbers, an
> application process of some sort can be put in place for various groups to
> petition for representation. If accepted, that group is given a single
> vote. A committee can be put together that is in charge of addressing the
> applications.


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

Re: [PHP-DEV] [RFC] JIT

[Larry Garfield]

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.

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

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

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

[Stanislav Malyshev]

Hi!

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


That's be great. I see there are 57 open bugs for imap, triaging them
would be a good start.

> RoundCube may roll its own, but I know the popular Horde IMP uses this
> extensively. 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.

Migrating to something more modern (and not dead :) would definitely be
great. May be not that easy though given that one has to keep both APIs
and mailbox formats (at least to some measure) for it to be useful.
Alternative imap implementation may be a good route too...
-- 
Stas Malyshev
smalys...@gmail.com

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

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

[Benjamin Morel]

> The problem comes if the share using the old names *doesn't* decline
enough (and how would we even know?).

We can't survey private projects, but we can run automated analysis tools
on a large number of open-source projects available on GitHub, and compile
statistics from them. I'd be happy to work on such a tool, should it be
useful some day.

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

> To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they *want* to upgrade their code to use it...

I do agree with you on that point: I'd rather offer brand new APIs, rather
than just fixing naming inconsistencies. There is so much more than fixing
naming inconsistencies. The error handling, in particular, should be given
some love, by throwing exceptions everywhere, instead of returning false /
triggering warnings. And I would love, too, either your "scalar methods"
approach, or array being an object with built-in map/filter/reduce...

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

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

On Thu, 31 Jan 2019 at 12:43, Rowan Collins  wrote:

> On Thu, 31 Jan 2019 at 10:53, Benjamin Morel 
> wrote:
>
>> 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?
>>
>
> I agree, it probably doesn't help the community; but it happens, both in
> open source projects, and in the many private code bases which are written
> in PHP. The more breaking changes we make in the language, the *more*
> likely it is that people will stay on old versions, where their code works
> without modification, and have a negative opinion of upgrades.
>
>
>
>> 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 problem comes if the share using the old names *doesn't* decline
> enough (and how would we even know?). 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.
>
> To be more positive, I am all for introducing new ways to do existing
> things in the language where they have real benefits to the user. For
> instance, a new file-handling API, with better error handling, and
> object-based streams, would be great; or a replacement for the frankly
> awful curl functions. Perhaps even a well-designed implementation of
> "scalar methods" (e.g. being able to write [1, 2,
> 3]->map($callback)->filter($callback);) would have users enthusiastic
> enough that they *want* to upgrade their code to use it, although it takes
> us close to "completely new language" territory.
>
> If we can persuade every user of PHP that the change is bringing them a
> real benefit to outweigh the cost of re-writing and re-learning, then we
> can make grand changes to the language; I don't think moving underscores
> around will ever do that.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

[PHP-DEV] Re: [VOTE] RFC: Unbundle ext/wddx

[Christoph M. Becker]

Hi!

The voting on

  

has ended, and it has unanimously been decided (30:0) to remove (aka.
unbundle) ext/wddx; it has also been decided (19:4:3:2) to deprecate the
extension and move it to PECL.  Thanks to all voters!

I'll provide a patch regarding the deprecation as soon as possible.

-- 
Christoph M. Becker

-- 
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 tor. 31. jan. 2019 kl. 20.17 skrev Chase Peeler :
> I don't know if there is a good way to implement it, but I definitely think 
> there is value in some sort of voice being given to those that use PHP to 
> build things, but don't contribute to the actual source.
>
> I think it's important, though, to make sure that developers that are out 
> there actually developing things with PHP (not to say that contributors don't 
> belong to that group) have a voice - I'm just wondering if that needs to be 
> defined in a more formal way. One statistic I just found says that almost 6 
> million websites are running PHP7. Even if we assume that it averages out to 
> where there is 1 developer for every 100 sites, that's still 60,000 
> developers being represented by 175 voters.

I do believe that the right to vote is a privilege of actually
contributing to the project, which in our case is seen by code as we
are a scripting language project, I think that is a fair definition.

However I do believe that because it is also a privilege it should be
considered as something you earn by dedicating yourself to the
project, if you are dedicated to the project then I would assume (and
I'm certain that I speak for most core developers) when I say that
those voting for changes in PHP does it in PHP's best interest.
Because they understand the complications and impact changing things
have.

We can take an example by looking at some of the more recent change
proposals for PHP8 that goes to show that not a lot of thought about
the implications and effect changing a few functions may have. For
your open source framework that have lets say maybe 10.000 users, that
is not a big deal, but when you take that number and maybe multiply it
by 1.000 (or you can swap around the zeros), then the impact of which
we change things are set in a very different perspective. Okay we do
have procedures for how to deal with some of these things for what can
and can't go into a branch. My point here is that when you are apart
of the project and more or less integrated with it, you would also
understand the ramifications on a project of the scale.

I do not want this to sound unwelcoming or so at all, I would like
more to join the project and put effort into improving our code base.
However like Johannes said in a mail earlier in this thread, if the
maintainers (core developers) are overruled by a third party, then a
point they simply loose interest and stop contributing and the project
will begin to halt. I would feel that same way myself.

> Maybe the voice that we currently have in the form of being able to 
> participate in these discussions is enough. I'd be interested in knowing how 
> often voters are persuaded to take a position on an issue after discussing it 
> with non-voting developers - whether via these discussion lists or on other 
> mediums.

I think the AFUP did something rather interesting, which we could use
as a model; If you are not familiar with the AFUP (Association
Française des Utilisateurs de PHP), then it is the french usergroup
for PHP. Every now and then, we used to get emails from a member of
their group that would post a small summary of their thoughts
regarding a certain RFC, whether they were infavor of it or not and
potential problems they see as userland.

That I believe could work much better, as in giving external projects
or organization a way to comment on an RFC (which I would hope more
would have done instead of just being silent) about the pros and cons.
As core developers we take comments and feedback (Yes we have heard
the striking feedback about the standard library) as close as we can
to make sure that we don't just do something that would literally
render a PHP based project unusable by a change we have done.

> Maybe instead of giving all members of PHP-FIG a vote, the RFC can be amended 
> to specify that PHP related groups with a certain number of active members 
> are given a single vote. Or, instead of membership numbers, an application 
> process of some sort can be put in place for various groups to petition for 
> representation. If accepted, that group is given a single vote. A committee 
> can be put together that is in charge of addressing the applications.

Please no committee or more bureaucracy as it just makes everything so
much more political and complicated for no satisfying reason.

-- 
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] PHAR maintainer?

[Stanislav Malyshev]

Hi!

> Do I need to request any special git access or just keep doing the usual
> PR process?

For now, just keep the PRs - ping me and/or this list if they linger too
long without review. Eventually I assume we'd just setup you access to
ext/phar but PRs seem to be good way for now to start without delay.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tor. 31. jan. 2019 kl. 19.04 skrev Zeev Suraski :
> 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 think we can easily agree on the fact that by no means Windows is
the top candidate for production. For me personally from a project
standpoint, I believe it is something important that we can have a PHP
that is pretty much as transparent and identical no matter what
platform you are on, which is something I have tried to do myself by
implementing various Linux routines for Windows natively to make PHP
as platform independent as possible.

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

With above being said, then I do also agree with you here, but I would
like to have such functionality and improvements to our core system be
as global as possible, naturally I don't think its fair either to
require it so desperately upfront, but it should be a heavy
consideration with the amount of work that we all have put into making
Windows support one of the best among programming languages of similar
category.

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

I don't think it would be fair either to simply dismiss the idea and
many years of hard work for a detail like platform support either, and
that is not the way I hope anyone would cast their vote.

> I think that if we reach the conclusion that Windows support is a must, we 
> can condition the inclusion of JIT based on having it.  Let's first agree on 
> whether we want it in the first place.

Agreed. Naturally I would contribute in what I can to work on those
parts (Windows).


-- 
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] PHAR maintainer?

[Bishop Bettini]

On Thu, Jan 31, 2019 at 3:13 PM Stanislav Malyshev 
wrote:

> Hi!
>
> > I've been fixing phar bugs here and there over the last year, and I'm
> > happy to take on a more diligent process to maintain ext/phar officially.
> >
> > Do we have, anywhere, a maintainers guide that talks about the
> > maintainers' responsibilities?
>
> First of all, thanks for volunteering!

There's no real formal guide, but basically maintainer should monitor
> the tickets filed against the extensions and provide fixes for them.

There seems to be a bunch of open ones:
>
> https://bugs.php.net/search.php?search_for=&boolean=0&limit=30&order_by=&direction=DESC&cmd=display&status=Open&bug_type=All&project=All&package_name%5B%5D=PHAR+related
>
> so making a pass over them, seeing which ones still exist and confirming
> them, closing those that don't happen anymore and starting fixing those
> that still happen would be a good start. If you need somebody to review,
> I'd be glad to help with whatever I can.
>

Excellent, that's exactly what I had started to do, before pausing to
welcome my son into the world. Being back at it, I've set a goal to triage
one bug a week, which positions us to be potentially phar bug free in about
a year. (Assuming the ingress rate of about 6/year remains stable.)

Some I've triaged quite a while ago, and I felt a more comprehensive
refactor would be appropriate. I'll leave those alone until I have more
total experience with the code and focus my first efforts on the low
hanging fruit.

Do I need to request any special git access or just keep doing the usual PR
process?

bishop

Re: [PHP-DEV] PHAR maintainer?

[Stanislav Malyshev]

Hi!

> I've been fixing phar bugs here and there over the last year, and I'm
> happy to take on a more diligent process to maintain ext/phar officially.
> 
> Do we have, anywhere, a maintainers guide that talks about the
> maintainers' responsibilities?

First of all, thanks for volunteering!
There's no real formal guide, but basically maintainer should monitor
the tickets filed against the extensions and provide fixes for them.
There seems to be a bunch of open ones:
https://bugs.php.net/search.php?search_for=&boolean=0&limit=30&order_by=&direction=DESC&cmd=display&status=Open&bug_type=All&project=All&package_name%5B%5D=PHAR+related

so making a pass over them, seeing which ones still exist and confirming
them, closing those that don't happen anymore and starting fixing those
that still happen would be a good start. If you need somebody to review,
I'd be glad to help with whatever I can.

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

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

Re: [PHP-DEV] PHAR maintainer?

[Bishop Bettini]

On Sun, Jan 20, 2019 at 9:01 PM Stanislav Malyshev 
wrote:

> Hi!
>
> PHAR is pretty widely used component of PHP ecosystem, as I understand,
> but all people listed as maintainers for the extension haven't been
> active in the project for a decade. Is there somebody still willing to
> take care of it?
>

I've been fixing phar bugs here and there over the last year, and I'm happy
to take on a more diligent process to maintain ext/phar officially.

Do we have, anywhere, a maintainers guide that talks about the maintainers'
responsibilities?

bishop

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

[Bishop Bettini]

On Thu, Jan 31, 2019 at 9:07 AM Zeev Suraski  wrote:

> On Thu, Jan 31, 2019 at 3:53 PM Kris Craig  wrote:
>
> > I think you may be over-reaching a bit on the eligible voters part.  Keep
> > in mind that all those who would be affected would still be able to vote
> on
> > this RFC.  I think it's too restrictive on that part.
> >
>
> I realized that this part of the RFC is likely to be challenging.  I'm open
> to additional ideas (or tweaking of existing ones) - but at the same time,
> I think the current situation is not sustainable - nor can I think about
> any other (large) Open Source project that employs anything similar.
> Today, any person can become a voter, with identical rights to long time,
> committed contributors - virtually overnight, with very little (or
> virtually no) commitment on their part.  Open Source project governance
> tends to be a meritocracy - and even this proposal sets a fairly low bar to
> having the very same voting rights as Rasmus, me, Nikita or Dmitry.  Again,
> I'm very open to ideas on how to improve on it, it's not an easy task to
> tackle.
>

I favor changing how we vote, but I disagree with the proposed unilateral
vote stripping. As requested, I will offer an idea.

We have two disparate groups contributing to PHP. One the one hand, we have
the "core developers" who disproportionally carry the most burden to build
and maintain the source. On the other hand, we have "the community" who
consume, organize, and evangelize PHP (and who may, or may not, commit).
Both of these groups change over time.

What outcomes do we desire?

   - A change Wanted by the simple majority of Both core developers and the
   community should Pass.
   - A change Unwanted by the simple majority of Both should Fail.
   - We require a higher standard of consensus when the majority of Either
   cannot agree.

I counter-propose the following voting rules, modeled after Robert's Rules
for voice and rising votes, which encourages a wider audience to join and
vote or to strive to contribute more to the engine:

   1. Anyone can register as a community member, and can vote on any RFC as
   a community member.
   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.
   3. Voting occur in rounds.
   4. Round one is the opening vote. If the simple majority of both parties
   consents, the vote passes. If the simple majority of both parties dissents,
   the vote fails. In either of these cases, the vote ends as consensus has
   been reached.
   5. Round two occurs when there is disagreement between parties. In this
   round, a 2/3 super-majority consent from one party carries the vote, unless
   there is a 2/3 super-majority dissent from the other party. If carried, the
   vote ends as "sufficient" consensus has been reached.
   6. Round three occurs when there is "excessive" disagreement on the
   topic. In this round, the elected tie-breaking member shall cast the
   deciding vote. If there is no elected tie-breaking member in service, the
   vote fails.

Administrative miscellany:

   1. Core developers' vote requires a quorum.
   2. Community members' voting does not require quorum.
   3. Voting rounds are open for one week from the opening date time. If a
   round times out without decision, the vote fails.
   4. The definition of core developers may itself be voted upon under
   these rules.
   5. The tie-breaking member shall be elected every two years under these
   rules.

I believe these rules respect the order we have now, while evening out the
representation and raising the bar on contentious votes. As with Zeev's
proposal, gone is the idea that RFC authors choose the bar, but instead of
mandating 2/3, this proposal focuses on the idea of consensus, and what it
means quantitatively. Added, as mentioned in Zeev's proposal as a Todo is
quorum, which protects the language from changes snuck in without the
explicit review of at least those who will be most responsible for it. Of
course unlike Zeev's proposal this encourages more involvement from the
community by saying "yes you have a vote".

Diverse representation, quantitative consensus, and mandatory quorum work
together to ensure we can continue collaboration under a rational framework
where everyone's voice is recorded and the majority does become tyrannical.

Thanks everyone for all you do and your consideration of this alternative,
bishop

[PHP-DEV] PHP 7.2.15RC1 is available for testing

[Christoph M. Becker]

Hi,

PHP 7.2.15RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.2.15RC1

The Windows binaries are supposed to be shortly available at:


Please test it carefully, and report any bugs in the bug system.
7.2.15 should be expected in 1 week (to stay in sync with 7.3.2), i.e.
on February 7th, 2019.

Hash values and PGP signatures can be found below or at
.

Thank you, and happy testing!

Regards,
Christoph M. Becker on behalf of Sara Golemon and Remi Collet

php-7.2.15RC1.tar.bz2
SHA256 hash:
b8e1fdad57ac12854bb6427e8652d4bf695407c057a84c89872654a578756c60
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJcUOpBAAoJENZslZMRi8y2Y3gQAJhPWh6MSFdqRo+pdWK0KcLl
2XpLAkpIWVAjqBjzcEE3U4sf2xzARX5pLCuGxKkU/7uZvZ/61MIUvA+4WEyDopCc
tSVn4ZZ7wqMPWSThCAvOl93XUOgxon3rP99Dazga1npHmCx+MXdEzxh4+D8Rlrbs
kDsBejip4RVJ25KghJgiD3NlqpYfkx9nwSJV/HwwEHm9vkk5+STeWCfOVCyOxnHl
+JOhzyChebWC62t3Cv07kc1YlifQcN+wo5+sTIZ6sRFmSE6N5LsmqDxaw0kvXYBH
R+Q94Q20AhFqbxB1HY8FJ+sIZMnHdlsIpS6hkiOKZkf/0L6noHWrX/buct4uI4Tj
7EYjl2ofV9fD0BbfcZ0rgIAdejLDGXdAXwjkxUjHHPGqq05SpYbKpynFwCvEQjGJ
3HaOUrC2GrY5gvRRTIo9pXNEWhuCNmylJO1xUnlH1kmmfDYek0mXl9F33glV8Y5P
/T5zXZFcZ6IurWC35e5A8fvTFXWfsRRVrCEg93na0NeO5usE6UqhuOZP9l6/QvEk
yphZladZ7qBLNiHT5Qa/iu+4deMkC/0wF4vz8RiWElvsmBPhHftZmTPAf55i6leL
H7L88R38sX9mO2RTKkyDhi1d7wYF+RRu+C2SvBlRUPPTJddr9m7ws62i3N08WObn
/iBFr9q6sDv/neQznk2p
=E91S
-END PGP SIGNATURE-


php-7.2.15RC1.tar.gz
SHA256 hash:
c65ea5b795cfe8d8ebdcc87280d59bb31e24a54459e8f76bc356151bbb76af52
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJcUOpVAAoJENZslZMRi8y2FrQP/RNbnK5nanGyTjmlcczZvVFq
+k6jNWZZqm+HUiOaL8foyPUNKiiY4W9tFsrTBY/nhpVQ7N3FFQLWTH1x18wGQhsy
y/YiT1G5j1STxUJKKPTMemhMGqhFMDsqqA+/XldmEjlz19NBMkSLMu3UntdnLApn
1oAiXIgwshIS+at0XLWLG7GnN5x2EkaN4qobUL7ZbpbDRc/LplF8e+MPdVGLVO16
ecE4gSntA03DIVVVsm8NoCkl9CnlhvCxMyjmQq8jO8wMY7i1tnmLAbf/jFOCZEX0
88JmyJMOTr9lknp1th68ktfclX4GndBS7T4cR3ctNJlGBpe4eO7u5tMNfyggjJ9E
c1GRSonj3vYO8cm0R8H/F+UVtwPnoJg1qcorvD6F7lm15YdLIvuKchhOlOuuSquo
MPhGRhmfx1Zm7IMcwYBqrnezXh+kNsQwLt2G5qODtkETByQwSkjshqDQDA9WCkP/
RE3LltNxfLlJAi+K2Xcf5Yu/HvVuY4D8A68d5+ZQqzYGDjuNBkhYeZQJsiE3Yjrp
eswrq342xczuaZblCUc4tJSqPrrhc8Klm4jvfJIhi7TNUj/R476aDkArDMscBofS
DWZLiGRmwC97gd1olk2ezqeMXgudYh0Sntva3GIOKjPLs2HRr+maj9WpNKKIEyOB
zkYannGQlKq+QoN+Rrw1
=UYmh
-END PGP SIGNATURE-


php-7.2.15RC1.tar.xz
SHA256 hash:
78590de2354695db1cd13dfdf653561cb1b7da84f9e34fa96332c7f92bb49eab
PGP signature:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJcUOpcAAoJENZslZMRi8y26HgP/RH665OBKDT8s+On8+RQqhlX
yxH8S+cmJI6SnYrMQGTOJWtKD9UOTL5D4rNmkn8UqOLr+4pmwJHCV5J9idn1uZ9J
1l1oQFTVw41gdeIBF7K0KyQmxRtYQPi9zIHUgs0dkL59xyjEY4lg6hPNvAua68dd
Rz1rnC39LMHoXFDz9+eTSOyfq2BEKsFt/iAbWuHazQ7jEGoduWPKL2OR5n2wLhBY
nIs5Ze4oX5TDBRgR2kS50uTHi65ZGqdYUh6bd2Du8ABzPwGz5Spyd72LomfvlCHC
IpC6bQegMQgShsX4aHkRISF+2VyEcSfQQII8YVgAGlfu1cIyim9pabmZ3FV82a6c
6xe0fVHfT3lOgvGRugRfzx4NswsFei5O+Iv16V27pBpkMeHSondhlhKsm8bqfoNS
8q2IKrDDkkHk4QxADDYZ8+3ekjN60XEZu754vmXdkWx8uo+DQ2Djs00bGaMP00zx
heTCE+CJXaYMEK1xC0RN1YFdmb4HXFtt6wg2ux873Z4ddvLN6RbIlhARUOXFJb61
TOylJjR9hu8Jepp/1WNDndQOkgmyU9lm0f7/PVv8PzeCtgmJ+/JU/uVuMpSidVuu
Zct6/fla97EZiSfUmuB9m2vFOA09Rvk35rqsrrtVV6tUcKAfOqfBVRAw/2JQ1CqY
G2Sh01UqU2UBuQ7dB7RZ
=PT2d
-END PGP SIGNATURE-

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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 1/31/19 9:12 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> 
>>
>>
>> On 1/31/19 8:08 PM, Derick Rethans wrote:
>>> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
>>>
 I'm glad to finally propose including JIT into PHP.

 https://wiki.php.net/rfc/jit
>>>
>>> I don't see anywhere in this RFC how it would affect thigns that do
>>> sneaky things with internals, such as Xdebug. How is that going to be
>>> affected?
>>>
>>
>> I suppose Xdebug should work on non-JIT-ed versions of the functions.
>> Even JVM deoptimizes to bytecode when debugging.
> 
> So, in that case, I think I would need to be able to instruct the PHP
> JIT engine to be turned off. Perhaps through an API?
> 
> Similarly, I think it might be useful for OPcache as well,

Use zend_alter_ini_entry() to set "opcache.enable" to "0".
Better to do it at RINIT.

Thanks. Dmitry.

> as I am
> getting more people confused why some breakpoints don't work, or
> variables don't exist:
> https://bugs.xdebug.org/view.php?id=1609
> 
> cheers,
> Derick
> 

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

Re: [PHP-DEV] [RFC] JIT

[Chase Peeler]

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.


> I think that if we reach the conclusion that Windows support is a must, we
> can condition the inclusion of JIT based on having it.  Let's first agree
> on whether we want it in the first place.
>
> Zeev
>
-- 
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Andrey Andreev]

Hi,

On Thu, Jan 31, 2019 at 5:28 PM Zeev Suraski  wrote:
>
> Secondly - the threshold and voting eligibility are not, in any way,
> independent.  They're two fundamental aspects of the same topic - how votes
> take place.  A 2/3 majority out of a subset of ~200-300 people is very
> different from a 2/3 majority out of a potential group of several thousand
> people
>

Does that really matter though? Your own proposal includes the 2/3
rule and I don't think you're saying 50%+1 is OK now, so what
difference does it make?
I don't see a reason why this RFC, which looks almost like just a
formality, should be bundled with something way bigger and
controversial.

Cheers,
Andrey.

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

[Chase Peeler]

On Thu, Jan 31, 2019 at 11:52 AM Zeev Suraski  wrote:

> On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen 
> wrote:
>
> > Hi Zeev
> >
> > Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> > >
> > > 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
> >
> > I wholeheartedly disagree with the PHP-FIG special exception to who
> > can vote, call me biased but I do not believe it serves any purpose
> > and is absurd. People who actively work on PHP, should be the ones to
> > be able to have a choice, I think that should be reserved for any
> > contributor who puts effort working on PHP.
> >
> > I do understand that we are the language and our work affects the
> > others the most. However making special exceptions for who can vote
> > and essentially having a say from an external source in what I in
> > theory need to help maintain as a PHP Core Developer is terrible. Why
> > not allow WordPress Core Developers to have a say instead, as their
> > work has a larger impact on the usage of PHP? (That was obviously a
> > bit of sarcasm, the last part). We are not allowed to vote at their
> > individual projects features (nor do we need to have a say if we are
> > not actively involved in the development of said projects or
> > organizations) and I stand very strongly behind that belief.
> >
>
> That's a very fair point.  I'm personally undecided on this.  It's fair to
> say that in 2011, my thinking was that voting rights should be given pretty
> much exclusively to contributors.  It may sound like overreaching, but the
> reality is that this is pretty much how ALL open source projects work (and
> have been working).  The reason it sounds overreaching, is that over the
> several years following the ratification of the 2011 Voting RFC - a status
> quo of "virtually anybody can vote" took hold, and it's now fairly
> entrenched in people's minds.  It's still very, very awkward when taken in
> the context of how OS projects behave in general.
> The thinking behind PHP-FIG (and for that matter, having some
> representation from WordPress, yes, I'm not kidding...) was to create
> something which goes a bit farther than what's usual in an OS project -
> because of the status quo we have today.  Making it a bit easier to
> digest.  But it may be that it's the wrong approach.  I'll be interested to
> see what others think about it as well.  I'm personally open both for
> extending that list further - or potentially trimming it down - making it
> more of a meritocracy, as is customary in virtually all other OS projects.
>
> I don't know if there is a good way to implement it, but I definitely
think there is value in some sort of voice being given to those that use
PHP to build things, but don't contribute to the actual source.

I think it's important, though, to make sure that developers that are out
there actually developing things with PHP (not to say that contributors
don't belong to that group) have a voice - I'm just wondering if that needs
to be defined in a more formal way. One statistic I just found says that
almost 6 million websites are running PHP7. Even if we assume that it
averages out to where there is 1 developer for every 100 sites, that's
still 60,000 developers being represented by 175 voters.

Maybe the voice that we currently have in the form of being able to
participate in these discussions is enough. I'd be interested in knowing
how often voters are persuaded to take a position on an issue after
discussing it with non-voting developers - whether via these discussion
lists or on other mediums.

Maybe instead of giving all members of PHP-FIG a vote, the RFC can be
amended to specify that PHP related groups with a certain number of active
members are given a single vote. Or, instead of membership numbers, an
application process of some sort can be put in place for various groups to
petition for representation. If accepted, that group is given a single
vote. A committee can be put together that is in charge of addressing the
applications.


> > Do I understand the PHP Packaging Decisions right that it requires to
> > vote for a timeline for each version? I remember we have different
> > opinions raised regarding the time to a new major version (should we
> > have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
> > regarding a 5.7). This is the only issue I can think of and should be
> > changed to requiring a vote if there is a dispute in regards to what
> > the next version should be. As I don't really wanna vote just to vote
> > for each of the minor versions of 8 once a year when its the most
> > logical reason to go to 8.1 from 8.0, and so on until we reach the
> > point where the next major is considerable.
> >
>
> I agree.  I'll look at the text and clarify it as needed.  Of course it
> makes no sense t

Re: [PHP-DEV] [RFC] JIT

[Derick Rethans]

On Thu, 31 Jan 2019, Dmitry Stogov wrote:

> 
> 
> On 1/31/19 8:08 PM, Derick Rethans wrote:
> > On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> > 
> >> I'm glad to finally propose including JIT into PHP.
> >>
> >> https://wiki.php.net/rfc/jit
> > 
> > I don't see anywhere in this RFC how it would affect thigns that do
> > sneaky things with internals, such as Xdebug. How is that going to be
> > affected?
> > 
> 
> I suppose Xdebug should work on non-JIT-ed versions of the functions.
> Even JVM deoptimizes to bytecode when debugging.

So, in that case, I think I would need to be able to instruct the PHP 
JIT engine to be turned off. Perhaps through an API? 

Similarly, I think it might be useful for OPcache as well, as I am 
getting more people confused why some breakpoints don't work, or 
variables don't exist:
https://bugs.xdebug.org/view.php?id=1609

cheers,
Derick

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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 7:00 PM Nikita Popov  wrote:

> 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
> number of RFCs have passed with narrow voting margins. Every time that
> happens, I think "damn, why didn't we go through with the voting threshold
> RFC?"
>
> This RFC has been delayed for various reasons in the past -- those reasons
> sounded good at the time, but the end effect is still the same: RFCs being
> accepted with unreasonable margins. If we delay this again and it turns out
> that your competing RFC stays in limbo for the next two years, or is simply
> not accepted due to changes unrelated to voting margins, I would consider
> that to be quite unfortunate.
>

I've had similar issues with other aspects of the shortcoming of the 2011
Voting RFC.  The 50%+1 vs 2/3 is really just one issue - it's an important
one, but just one - and it doesn't live in vacuum.  It's interrelated to
other issues.


> If you have concerns with the details of the rules outlined in this RFC,
> I'm sure that Joe is open to discussing them. But let's please make sure
> that this particular question is resolved in a timely manner, which I think
> requires it to be tackled separately from other issues.
>

To me, changing the margins is like placing a band-aid on a gunshot wound.
Or perhaps to be more fair, it's to start surgery on wound, but then
stopping a 3rd way through or so.
Unless the RFC is extended to cover all the key shortcomings of the 2011
Voting RFC, then it's a superficial fix that I can't be in favor of.
 Rushing it through bears the hallmarks of the issues that plagued the 2011
Voting RFC - putting something together quickly, not trying to think
through all of the different scenarios and consequently not providing a
comprehensive solution.

Is the 2011 Voting RFC + permanent 2/3 margins still deeply flawed?  I'd
say absolutely yes.  Then let's think on how we fix it holistically.

If your concern is that RFCs would pass under this low margin as we debate
- why not call for a 30 day pause on RFC votes altogether (extensible by
another 30 days assuming there's still a healthy discussion), not just for
JIT?  I'm all for it.  We have the time and apparently now also the
inclination, let's finally settle this thing and make it right.

Zeev

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 1/31/19 8:08 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> 
>> I'm glad to finally propose including JIT into PHP.
>>
>> https://wiki.php.net/rfc/jit
> 
> I don't see anywhere in this RFC how it would affect thigns that do
> sneaky things with internals, such as Xdebug. How is that going to be
> affected?
> 

I suppose Xdebug should work on non-JIT-ed versions of the functions.
Even JVM deoptimizes to bytecode when debugging.

Thanks. Dmitry.

>> 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.
> 
> I do not believe that something major like this should make it into any
> PHP 7.x release. Having it as experimental new feature in the master/PHP
> 8.0 branch makes the most sense to me.
> 
> cheers,
> Derick
> 

Re: [PHP-DEV] [RFC] JIT

[Derick Rethans]

On Thu, 31 Jan 2019, Dmitry Stogov wrote:

> I'm glad to finally propose including JIT into PHP.
> 
> https://wiki.php.net/rfc/jit

I don't see anywhere in this RFC how it would affect thigns that do 
sneaky things with internals, such as Xdebug. How is that going to be 
affected?

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

I do not believe that something major like this should make it into any 
PHP 7.x release. Having it as experimental new feature in the master/PHP 
8.0 branch makes the most sense to me.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

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?

I think that if we reach the conclusion that Windows support is a must, we
can condition the inclusion of JIT based on having it.  Let's first agree
on whether we want it in the first place.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Thu, Jan 31, 2019 at 4:27 PM Zeev Suraski  wrote:

>
>
> On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov  wrote:
>
>> I agree with Joe here that we should handle the question of voting margins
>> separately. Your RFC is a much more comprehensive reform, which contains a
>> number of points that look highly controversial to me (such as the
>> eligible
>> voter changes). It may take a long time until we reach a satisfactory
>> consensus there.
>>
>> On the other hand, this RFC is very simple and at least to me a complete
>> no-brainer. I already use 2/3 majority for all my votes, because I very
>> strongly believe that changes to PHP need to be held to a much higher
>> standard than a simple majority. It is outright shameful that
>> functionality
>> can be added to PHP if 21 vote in favor and 20 against. That's not a
>> consensus, that's a complete disagreement.
>>
>> It's not necessary to decide all questions regarding the RFC process at
>> once. Voting threshold is a very self-contained issue and we can decide it
>> separately from other controversial changes.
>
>
> Well, I think there are several issues here.
>
> One - while the passing threshold is probably one of the most painful
> issues with the current Voting RFC, it's hardly the only one.  Given it's
> taken us many years to start tackling this, I think it's safe to say that
> as a rule, we lack the motivation to tackle these issues.  I think it's
> pretty clear that if we solve the threshold issue independently, it would
> likely be years before we tackle the other issues, if ever.
>
> Secondly - the threshold and voting eligibility are not, in any way,
> independent.  They're two fundamental aspects of the same topic - how votes
> take place.  A 2/3 majority out of a subset of ~200-300 people is very
> different from a 2/3 majority out of a potential group of several thousand
> people
>
> Thirdly - implementation issues - that the original Voting RFC did NOT
> intend to cover, later became covered by it by virtue of assumption.  I
> think that implementation issues (implementing the same functionality that
> we have right now in a better way) should not be subject to a vote, and
> moving the threshold to 2/3 makes the current situation even worse than it
> currently is, and should be for the most part up to the maintainers of the
> code.
>
> So no, I don't think we can simply 'abolish narrow margins' without
> thinking about the implications as well as tackling the other shortcomings
> of the 2011 Voting RFC.  With due respect, it reminds me of the hasty
> approach we took back then, and that wasn't good.
>
> Unless I'm missing something, we're currently in absolutely no hurry - we
> just released 7.3, we can spend as much time as needed (to a reason) on
> hashing out updated voting rules.  I'm speaking on behalf of myself, and
> maybe Dmitry thinks differently - but I'm certainly fine waiting with that
> RFC for several weeks or even a couple of months if needed.
>
> Zeev
>

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
number of RFCs have passed with narrow voting margins. Every time that
happens, I think "damn, why didn't we go through with the voting threshold
RFC?"

This RFC has been delayed for various reasons in the past -- those reasons
sounded good at the time, but the end effect is still the same: RFCs being
accepted with unreasonable margins. If we delay this again and it turns out
that your competing RFC stays in limbo for the next two years, or is simply
not accepted due to changes unrelated to voting margins, I would consider
that to be quite unfortunate.

If you have concerns with the details of the rules outlined in this RFC,
I'm sure that Joe is open to discussing them. But let's please make sure
that this particular question is resolved in a timely manner, which I think
requires it to be tackled separately from other issues.

Regarding your point about implementation issues: I'm not really sure I
understand it. Generally implementation issues are decided by a small group
of people (usually Dmitry, Bob and myself), often without even going
through the internals list. Of course very large changes (like say phpng)
should go through the RFC process simply because they affect many more
people (in particular also extension authors). Apart from that, I'm not
sure which other "implementation" RFCs you have in mind here.

Regards,
Nikita

PS: I think this thread went thoroughly off track and now mostly discusses
the FFI extension rather than this RFC ... Maybe that should be moved
elsewhere?

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

On 1/31/19 7:23 PM, Joe Watkins wrote:
> Hi Zeev, Dmitry,
> 
> It is not my only concern, I'm grateful for the clarification whatever.
> 
> These are your actual words from the RFC:
> 
>  > This works, but this functionality is not supported on all libffi 
> platforms, it is not efficient and leaks resources by the end of 
> request. It's recommended to minimize the usage of PHP callbacks.

Do you understand what is PHP callback in context of FFI?
In the following example, it's used to override zend_write by PHP 
function, but FFI can't know when this callback is not used by C 
anymore, and keeps it until the end of request.

zend_write;
$zend->zend_write = function($str, $len) {
global $orig_zend_write;
$orig_zend_write("{\n\t", 3);
$ret = $orig_zend_write($str, $len);
$orig_zend_write("}\n", 2);
return $ret;
};
echo "Hello World!\n";
$zend->zend_write = $orig_zend_write;
?>

> To me, a foreign function interface where one side of the interface 
> sounds broken and inefficient, according to the author, is scary. I've 
> never worked with libffi, so don't know if that's normal ... but I think 
> you can understand my thoughts here.

There is the same issue with FFI for LuaJIT.
I'm not sure if Python CFFI supports callbacks.

> Aside from whatever technical issues I may have misinterpreted or 
> misidentified, these are not my main objections to it being merged.

I got it.

Thanks. Dmitry.

> 
> Cheers
> Joe
> 
> On Thu, 31 Jan 2019 at 17:20, Zeev Suraski  > wrote:
> 
> 
> 
> On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  > wrote:
> 
> The fact that FFI may leak, is because it uses "unmanaged
> memory" (like
> in real C). PHP reference counting and GC just can't handle all the
> cases. It's impossible to automatically know what to do with C
> pointer,
> when we get it from function or another structure. In this case
> programmer have to care about freeing the pointer themselves
> (like in C).
> 
> This obviously doesn't count as 'leaks'.  If it did, we could say
> that the Zend Extension API leaks, as it's completely up to the
> developer to handle memory management.
> 
> Joe - if that's your concern, I think it's fair to say it's
> invalid and you have nothing to worry about.
> 
> Zeev
> 

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

[Zeev Suraski]

On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen  wrote:

> Hi Zeev
>
> Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> >
> > 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
>
> I wholeheartedly disagree with the PHP-FIG special exception to who
> can vote, call me biased but I do not believe it serves any purpose
> and is absurd. People who actively work on PHP, should be the ones to
> be able to have a choice, I think that should be reserved for any
> contributor who puts effort working on PHP.
>
> I do understand that we are the language and our work affects the
> others the most. However making special exceptions for who can vote
> and essentially having a say from an external source in what I in
> theory need to help maintain as a PHP Core Developer is terrible. Why
> not allow WordPress Core Developers to have a say instead, as their
> work has a larger impact on the usage of PHP? (That was obviously a
> bit of sarcasm, the last part). We are not allowed to vote at their
> individual projects features (nor do we need to have a say if we are
> not actively involved in the development of said projects or
> organizations) and I stand very strongly behind that belief.
>

That's a very fair point.  I'm personally undecided on this.  It's fair to
say that in 2011, my thinking was that voting rights should be given pretty
much exclusively to contributors.  It may sound like overreaching, but the
reality is that this is pretty much how ALL open source projects work (and
have been working).  The reason it sounds overreaching, is that over the
several years following the ratification of the 2011 Voting RFC - a status
quo of "virtually anybody can vote" took hold, and it's now fairly
entrenched in people's minds.  It's still very, very awkward when taken in
the context of how OS projects behave in general.
The thinking behind PHP-FIG (and for that matter, having some
representation from WordPress, yes, I'm not kidding...) was to create
something which goes a bit farther than what's usual in an OS project -
because of the status quo we have today.  Making it a bit easier to
digest.  But it may be that it's the wrong approach.  I'll be interested to
see what others think about it as well.  I'm personally open both for
extending that list further - or potentially trimming it down - making it
more of a meritocracy, as is customary in virtually all other OS projects.


> Do I understand the PHP Packaging Decisions right that it requires to
> vote for a timeline for each version? I remember we have different
> opinions raised regarding the time to a new major version (should we
> have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
> regarding a 5.7). This is the only issue I can think of and should be
> changed to requiring a vote if there is a dispute in regards to what
> the next version should be. As I don't really wanna vote just to vote
> for each of the minor versions of 8 once a year when its the most
> logical reason to go to 8.1 from 8.0, and so on until we reach the
> point where the next major is considerable.
>

I agree.  I'll look at the text and clarify it as needed.  Of course it
makes no sense to have to vote on every version from scratch every time.


> I think changes like the requiring a patch for RFCs is a very welcomed
> addition.
>

Thanks for the feedback!

Zeev

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

[Johannes Schlüter]

On Do, 2019-01-31 at 15:44 +0200, 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
> 

Being mostly outside I wonder a bit whether it would make sense that
inactive developers at some point lose their voting right.

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. 

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.

johannes


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

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

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

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.

-- 
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 Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 5:56 PM Joe Watkins  wrote:

> When I refer to "you", I really mean you and Dmitry, while you don't have
> a hive mind, you do act as one, or for one another in a lot of cases. If
> I'm wrong about that, I apologise.
>

You are wrong, apology accepted.


> > I would say that Dmitry has by far the best track record of fixing any
> outstanding issues
>
> I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
> said it had leaks ... what am I supposed to think about that ? If someone
> does a patch for /Zend and it leaks or is suboptimal in any way, it does
> not land on Dmitry's say so, but it's okay for him to merge stuff with
> known defects ... I think the problem there is quite clear.
>

See separate reply from both Dmitry and me.  Sounds like a large part of
what brought you to vote against FFI was misunderstanding of the
situation.  Which I guess can still be blamed on the RFC author, but at
least, this concern should be alleviated now.

> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
>
> So you want to say that for FFI to be used, it had to be included in
> php-src ? That's nonsense, the kind of people who are capable of using FFI
> are also capable of installing an extension.
>

Joe, please, this language is counter-productive. Even more so when you're
first putting words in my mouth, but also without it.  Can we discuss
things politely without telling the other party that they're being
nonsensical?

I did not say that that "it had to be included in php-src in order to be
used".  Neither does ext/mysqli or any other extension for that matter.  I
*did* and *am* saying that it will *promote* its usage.  As is the case
with most promotions - the lack of promotion does not necessarily mean
complete and utter failure, but the presence of promotion may yield better
results than without it.  I very much stand by my statement that bundling
extensions in PHP is predominantly about promotion and ease of use, than it
is about technical requirements.


> From my perspective it had no justification for being merged at all, but
> there were very good reasons to keep it out of php-src not least the slim
> majority on which it was merged.
>

It wasn't such a slim majority, it was 62% IIRC, which is a lot closer to
the 2/3 needed than the 1/2 that was defined for it.  That said, I think
it's sad it didn't clear the vote with a much higher margin - well above
2/3 - and I'm making a cautious bet than misunderstandings around potential
leaks may have had something to do with it, and had it been clear that
these potential "leaks" are in fact an inherent element of FFI, and not a
limitation of the implementation - it would likely have gotten a lot fewer
negative votes.

> I actually agree with you that the fact it didn't clear a 2/3 vote, and
> with a hefty margin - is not very ideal.
>
> So it sounds like we agree here, it was pushed into php-src on an
> unacceptable margin.
>

"Unacceptable" is your statement, not mine.  We're not in a black and white
world - it's grey.  I think that with the current rules, it's 100.0%
acceptable.  Would I prefer that it cleared the vote with a much higher,
80-90% margin?  Yes.

For JIT, which is a much bigger deal in every respect compared to FFI, I
think it makes sense to take a pause and make sure we have our rules in
order before we move forward.

> I categorically disagree that it is an incomplete feature;  I presume
> you're saying this because it currently supports Linux x86/x64?
>
> This sounds disingenuous to me, you are trying to make it sound ready
> before it actually is.
>

 I can't control what it sounds like to you.  I can only control what I
say, and I know that I'm saying it with 100% sincerity based on my view of
the world and the importance of the different deployment platforms in the
PHP space.

>  It's not unusual for complicated pieces of software to first be
> available for specific subsets of platforms, and than gradually be ported
> to others
>
> That's true, but Windows is a core platform for PHP, if you haven't got
> Windows, you got nothing.
>

As the person who made PHP a first class citizen under Windows back in the
day (based on tons of prior work by Shane Caraveo), I wholeheartedly
disagree.

Windows support is not *nearly* as important as Linux support, especially
not when we deal with production systems - which is what JIT is geared at.
Windows it a tiny tiny fraction compared to Linux as far as deployments are
concerned.  The situation is different when we deal with development - but
that's mostly orthogonal to JIT (again, a production feature) - plus recent
trends make it even less of an issue, as even a developer running Windows
is today more likely to be running PHP in a Linux container/VM, than
natively on Windows.

I wouldn't make such a fuss about windows or fancy architectures, if I
> thought there was anyone

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 1/31/19 7:01 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.
> 
> 
> 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.

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

XDebug may work with JIT or opcache disabled.

> 
> I think those are the main points that come to mind right now...

Anyway, I'm mostly agree with all the points.

There are two options :)
- take the challenge and start developing JIT together
- forget about JIT, because we are afraid

Thanks. Dmitry.

> 
> Regards,
> Nikita

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Hi Zeev, Dmitry,

It is not my only concern, I'm grateful for the clarification whatever.

These are your actual words from the RFC:

> This works, but this functionality is not supported on all libffi
platforms, it is not efficient and leaks resources by the end of request.
It's recommended to minimize the usage of PHP callbacks.

To me, a foreign function interface where one side of the interface sounds
broken and inefficient, according to the author, is scary. I've never
worked with libffi, so don't know if that's normal ... but I think you can
understand my thoughts here.

Aside from whatever technical issues I may have misinterpreted or
misidentified, these are not my main objections to it being merged.

Cheers
Joe

On Thu, 31 Jan 2019 at 17:20, Zeev Suraski  wrote:

>
>
> On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  wrote:
>
>> The fact that FFI may leak, is because it uses "unmanaged memory" (like
>> in real C). PHP reference counting and GC just can't handle all the
>> cases. It's impossible to automatically know what to do with C pointer,
>> when we get it from function or another structure. In this case
>> programmer have to care about freeing the pointer themselves (like in C).
>>
>> This obviously doesn't count as 'leaks'.  If it did, we could say that
> the Zend Extension API leaks, as it's completely up to the developer to
> handle memory management.
>
> Joe - if that's your concern, I think it's fair to say it's invalid and
> you have nothing to worry about.
>
> Zeev
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  wrote:

> The fact that FFI may leak, is because it uses "unmanaged memory" (like
> in real C). PHP reference counting and GC just can't handle all the
> cases. It's impossible to automatically know what to do with C pointer,
> when we get it from function or another structure. In this case
> programmer have to care about freeing the pointer themselves (like in C).
>
> This obviously doesn't count as 'leaks'.  If it did, we could say that the
Zend Extension API leaks, as it's completely up to the developer to handle
memory management.

Joe - if that's your concern, I think it's fair to say it's invalid and you
have nothing to worry about.

Zeev

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

[Kalle Sommer Nielsen]

Hi Kris

Den tor. 31. jan. 2019 kl. 18.03 skrev Kris Craig :
> Given how complex and controversial this question of restricting who can vote 
> is, I propose that it be moved to its own RFC instead of being bundled with 
> this one.  It would certainly boost likelihood of passage, if nothing else, 
> as there are a lot of good ideas in this RFC.

While that makes sense, I do believe it should be sorted at the same
time. This can be solved by secondary votes on how to approach it
within the RFC.


-- 
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 Abolish Narrow Margins

[Dmitry Stogov]

Hi Joe,

On 1/31/19 6:56 PM, Joe Watkins wrote:
> Afternoon Zeev,
> 
>> I'll happily take your interpretation of it.  No hard feelings.
> 
> Thanks, you know I don't have another way of being :)
> 
> When I refer to "you", I really mean you and Dmitry, while you don't have a
> hive mind, you do act as one, or for one another in a lot of cases. If I'm
> wrong about that, I apologise.
> 
>> I would say that Dmitry has by far the best track record of fixing any
> outstanding issues
> 
> I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
> said it had leaks ... what am I supposed to think about that ? If someone
> does a patch for /Zend and it leaks or is suboptimal in any way, it does
> not land on Dmitry's say so, but it's okay for him to merge stuff with
> known defects ... I think the problem there is quite clear.

The fact that FFI may leak, is because it uses "unmanaged memory" (like 
in real C). PHP reference counting and GC just can't handle all the 
cases. It's impossible to automatically know what to do with C pointer, 
when we get it from function or another structure. In this case 
programmer have to care about freeing the pointer themselves (like in C).

This is all about the FFI leaks.

Thanks. Dmitry.

> 
>> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
> 
> So you want to say that for FFI to be used, it had to be included in
> php-src ? That's nonsense, the kind of people who are capable of using FFI
> are also capable of installing an extension. From my perspective it had no
> justification for being merged at all, but there were very good reasons to
> keep it out of php-src not least the slim majority on which it was merged.
> 
>> I actually agree with you that the fact it didn't clear a 2/3 vote, and
> with a hefty margin - is not very ideal.
> 
> So it sounds like we agree here, it was pushed into php-src on an
> unacceptable margin.
> 
>> I categorically disagree that it is an incomplete feature;  I presume
> you're saying this because it currently supports Linux x86/x64?
> 
> This sounds disingenuous to me, you are trying to make it sound ready
> before it actually is.
> 
>>   It's not unusual for complicated pieces of software to first be
> available for specific subsets of platforms, and than gradually be ported
> to others
> 
> That's true, but Windows is a core platform for PHP, if you haven't got
> Windows, you got nothing. I wouldn't make such a fuss about windows or
> fancy architectures, if I thought there was anyone around who could
> actually implement them, as far as I know there isn't and if they are
> unimportant to dmitry and yourself, then it won't get done.
> 
>> I think there were questionable decisions that happened long before
> FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
> for them specifically.
> 
> Check the date on the rfc, nothing is happening suddenly.
> 
>>   I'm not fine with rushing to hastily change the rules (while breaking
> the existing ones) to counter a specific RFC.
> 
> As I have already explained, I'm prompted to act because of a pattern of
> behaviour and decisions that I find questionable, and so do others ... and
> by your own admission, so do you ...
> 
> I should make clear that I think FFI is really cool although I haven't
> found time to play with it yet, and clearly I want us to have a JIT, and
> marvel at the achievement. I can't wait to start reading it (again) and
> trying to understand. This is not about one or two RFCs, but making simple
> changes to give us more confidence in the decisions we are all making, and
> it certainly isn't an attack on you or Dmitry, nothing of the sort ...
> 
> I think we don't really have anything to argue about, and to reiterate, I
> will be taking this RFC to vote.
> 
> Cheers
> Joe
> 
> 
> On Thu, 31 Jan 2019 at 16:13, Zeev Suraski  wrote:
> 
>>
>>
>> On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:
>>
>>> Afternoon Zeev,
>>>
>>> I'm going to use unambiguous and direct language to make sure my
>>> intentions
>>> and concerns are communicated clearly, you can either receive this as a
>>> personal attack, or as a contributor being direct, I would prefer the
>>> latter.
>>>
>>
>> I fail to see how in the way it was written it could not be taken as a
>> personal attack, but since you wrote it, I'll happily take your
>> interpretation of it.  No hard feelings.
>>
>>
>>> You pushed FFI into php-src on a simple majority
>>
>>
>> I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
>> but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
>> same person, nor do we have a hive mind...
>>
>>
>>> was
>>> incomplete (with leaks),
>>
>>
>> I would say that Dmitry has by far the best track record of fixing any
>> outstanding issues - not only with his code, but with the code of mostly
>> everyone else contributing to PHP, so if the

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

[Kris Craig]

On Thu, Jan 31, 2019, 7:58 AM Kalle Sommer Nielsen  Hi Zeev
>
> Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> >
> > 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
>
> I wholeheartedly disagree with the PHP-FIG special exception to who
> can vote, call me biased but I do not believe it serves any purpose
> and is absurd. People who actively work on PHP, should be the ones to
> be able to have a choice, I think that should be reserved for any
> contributor who puts effort working on PHP.
>
> I do understand that we are the language and our work affects the
> others the most. However making special exceptions for who can vote
> and essentially having a say from an external source in what I in
> theory need to help maintain as a PHP Core Developer is terrible. Why
> not allow WordPress Core Developers to have a say instead, as their
> work has a larger impact on the usage of PHP? (That was obviously a
> bit of sarcasm, the last part). We are not allowed to vote at their
> individual projects features (nor do we need to have a say if we are
> not actively involved in the development of said projects or
> organizations) and I stand very strongly behind that belief.
>
> Besides this, it also creates uncertainty about who elects such, and
> simply should be dropped from the voting RFC as it was already fairly
> unclear from the original one.
>
> The contributors appendix also lists ChangeLog, SVN Migration etc,
> something to keep in mind if this RFC is moved forward to filter the
> list.
>
>
> Do I understand the PHP Packaging Decisions right that it requires to
> vote for a timeline for each version? I remember we have different
> opinions raised regarding the time to a new major version (should we
> have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
> regarding a 5.7). This is the only issue I can think of and should be
> changed to requiring a vote if there is a dispute in regards to what
> the next version should be. As I don't really wanna vote just to vote
> for each of the minor versions of 8 once a year when its the most
> logical reason to go to 8.1 from 8.0, and so on until we reach the
> point where the next major is considerable.
>
>
> I think changes like the requiring a patch for RFCs is a very welcomed
> addition.
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Given how complex and controversial this question of restricting who can
vote is, I propose that it be moved to its own RFC instead of being bundled
with this one.  It would certainly boost likelihood of passage, if nothing
else, as there are a lot of good ideas in this RFC.

--Kris

>
>

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

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

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

[Kalle Sommer Nielsen]

Hi Zeev

Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
>
> 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

I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.

I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.

Besides this, it also creates uncertainty about who elects such, and
simply should be dropped from the voting RFC as it was already fairly
unclear from the original one.

The contributors appendix also lists ChangeLog, SVN Migration etc,
something to keep in mind if this RFC is moved forward to filter the
list.


Do I understand the PHP Packaging Decisions right that it requires to
vote for a timeline for each version? I remember we have different
opinions raised regarding the time to a new major version (should we
have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
regarding a 5.7). This is the only issue I can think of and should be
changed to requiring a vote if there is a dispute in regards to what
the next version should be. As I don't really wanna vote just to vote
for each of the minor versions of 8 once a year when its the most
logical reason to go to 8.1 from 8.0, and so on until we reach the
point where the next major is considerable.


I think changes like the requiring a patch for RFCs is a very welcomed addition.

-- 
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 Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

> I'll happily take your interpretation of it.  No hard feelings.

Thanks, you know I don't have another way of being :)

When I refer to "you", I really mean you and Dmitry, while you don't have a
hive mind, you do act as one, or for one another in a lot of cases. If I'm
wrong about that, I apologise.

> I would say that Dmitry has by far the best track record of fixing any
outstanding issues

I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
said it had leaks ... what am I supposed to think about that ? If someone
does a patch for /Zend and it leaks or is suboptimal in any way, it does
not land on Dmitry's say so, but it's okay for him to merge stuff with
known defects ... I think the problem there is quite clear.

> Functionality isn't everything.  Very few extensions have a technical
requirement to be bundled - it's much more of a question of promotion.

So you want to say that for FFI to be used, it had to be included in
php-src ? That's nonsense, the kind of people who are capable of using FFI
are also capable of installing an extension. From my perspective it had no
justification for being merged at all, but there were very good reasons to
keep it out of php-src not least the slim majority on which it was merged.

> I actually agree with you that the fact it didn't clear a 2/3 vote, and
with a hefty margin - is not very ideal.

So it sounds like we agree here, it was pushed into php-src on an
unacceptable margin.

> I categorically disagree that it is an incomplete feature;  I presume
you're saying this because it currently supports Linux x86/x64?

This sounds disingenuous to me, you are trying to make it sound ready
before it actually is.

>  It's not unusual for complicated pieces of software to first be
available for specific subsets of platforms, and than gradually be ported
to others

That's true, but Windows is a core platform for PHP, if you haven't got
Windows, you got nothing. I wouldn't make such a fuss about windows or
fancy architectures, if I thought there was anyone around who could
actually implement them, as far as I know there isn't and if they are
unimportant to dmitry and yourself, then it won't get done.

> I think there were questionable decisions that happened long before
FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
for them specifically.

Check the date on the rfc, nothing is happening suddenly.

>  I'm not fine with rushing to hastily change the rules (while breaking
the existing ones) to counter a specific RFC.

As I have already explained, I'm prompted to act because of a pattern of
behaviour and decisions that I find questionable, and so do others ... and
by your own admission, so do you ...

I should make clear that I think FFI is really cool although I haven't
found time to play with it yet, and clearly I want us to have a JIT, and
marvel at the achievement. I can't wait to start reading it (again) and
trying to understand. This is not about one or two RFCs, but making simple
changes to give us more confidence in the decisions we are all making, and
it certainly isn't an attack on you or Dmitry, nothing of the sort ...

I think we don't really have anything to argue about, and to reiterate, I
will be taking this RFC to vote.

Cheers
Joe


On Thu, 31 Jan 2019 at 16:13, Zeev Suraski  wrote:

>
>
> On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:
>
>> Afternoon Zeev,
>>
>> I'm going to use unambiguous and direct language to make sure my
>> intentions
>> and concerns are communicated clearly, you can either receive this as a
>> personal attack, or as a contributor being direct, I would prefer the
>> latter.
>>
>
> I fail to see how in the way it was written it could not be taken as a
> personal attack, but since you wrote it, I'll happily take your
> interpretation of it.  No hard feelings.
>
>
>> You pushed FFI into php-src on a simple majority
>
>
> I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
> but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
> same person, nor do we have a hive mind...
>
>
>> was
>> incomplete (with leaks),
>
>
> I would say that Dmitry has by far the best track record of fixing any
> outstanding issues - not only with his code, but with the code of mostly
> everyone else contributing to PHP, so if there's one contributor where this
> isn't something to worry about - that's him.
>
>
>> and had zero justification for being included in
>> php-src - it didn't require any internal API's and can function just fine
>> as a PECL extension
>
>
> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
>
>
>> still you pushed through with the RFC and it was
>> accepted on a simple majority.
>>
>
> I did not push this RFC in any way, nor did I even try to ask others to
> vote for it (which I would have if I was 'pushing' it).  I actually agree
> with you 

[PHP-DEV] Refactor zend_object_handlers API to pass zend_object* and zend_string* insted of zval(s)

[Dmitry Stogov]

Hi Nikita,


We already discussed this few months ago in context of PHP-7.4.

Please review the updated PR for master.


https://github.com/php/php-src/pull/3780


Thanks. Dmitry.

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov  wrote:

> I agree with Joe here that we should handle the question of voting margins
> separately. Your RFC is a much more comprehensive reform, which contains a
> number of points that look highly controversial to me (such as the eligible
> voter changes). It may take a long time until we reach a satisfactory
> consensus there.
>
> On the other hand, this RFC is very simple and at least to me a complete
> no-brainer. I already use 2/3 majority for all my votes, because I very
> strongly believe that changes to PHP need to be held to a much higher
> standard than a simple majority. It is outright shameful that functionality
> can be added to PHP if 21 vote in favor and 20 against. That's not a
> consensus, that's a complete disagreement.
>
> It's not necessary to decide all questions regarding the RFC process at
> once. Voting threshold is a very self-contained issue and we can decide it
> separately from other controversial changes.


Well, I think there are several issues here.

One - while the passing threshold is probably one of the most painful
issues with the current Voting RFC, it's hardly the only one.  Given it's
taken us many years to start tackling this, I think it's safe to say that
as a rule, we lack the motivation to tackle these issues.  I think it's
pretty clear that if we solve the threshold issue independently, it would
likely be years before we tackle the other issues, if ever.

Secondly - the threshold and voting eligibility are not, in any way,
independent.  They're two fundamental aspects of the same topic - how votes
take place.  A 2/3 majority out of a subset of ~200-300 people is very
different from a 2/3 majority out of a potential group of several thousand
people

Thirdly - implementation issues - that the original Voting RFC did NOT
intend to cover, later became covered by it by virtue of assumption.  I
think that implementation issues (implementing the same functionality that
we have right now in a better way) should not be subject to a vote, and
moving the threshold to 2/3 makes the current situation even worse than it
currently is, and should be for the most part up to the maintainers of the
code.

So no, I don't think we can simply 'abolish narrow margins' without
thinking about the implications as well as tackling the other shortcomings
of the 2011 Voting RFC.  With due respect, it reminds me of the hasty
approach we took back then, and that wasn't good.

Unless I'm missing something, we're currently in absolutely no hurry - we
just released 7.3, we can spend as much time as needed (to a reason) on
hashing out updated voting rules.  I'm speaking on behalf of myself, and
maybe Dmitry thinks differently - but I'm certainly fine waiting with that
RFC for several weeks or even a couple of months if needed.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:

> Afternoon Zeev,
>
> I'm going to use unambiguous and direct language to make sure my intentions
> and concerns are communicated clearly, you can either receive this as a
> personal attack, or as a contributor being direct, I would prefer the
> latter.
>

I fail to see how in the way it was written it could not be taken as a
personal attack, but since you wrote it, I'll happily take your
interpretation of it.  No hard feelings.


> You pushed FFI into php-src on a simple majority


I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
same person, nor do we have a hive mind...


> was
> incomplete (with leaks),


I would say that Dmitry has by far the best track record of fixing any
outstanding issues - not only with his code, but with the code of mostly
everyone else contributing to PHP, so if there's one contributor where this
isn't something to worry about - that's him.


> and had zero justification for being included in
> php-src - it didn't require any internal API's and can function just fine
> as a PECL extension


Functionality isn't everything.  Very few extensions have a technical
requirement to be bundled - it's much more of a question of promotion.


> still you pushed through with the RFC and it was
> accepted on a simple majority.
>

I did not push this RFC in any way, nor did I even try to ask others to
vote for it (which I would have if I was 'pushing' it).  I actually agree
with you that the fact it didn't clear a 2/3 vote, and with a hefty margin
- is not very ideal.

You are now trying to push JIT into php-src on the same slim, clearly
> unacceptable majority, and even if you change the majority requirements,
> what's worse is you want to include it in a minor version. Once again, this
> is an incomplete feature, failing to support the architectures we support
> and declaring them unimportant.


I categorically disagree that it is an incomplete feature;  I presume
you're saying this because it currently supports Linux x86/x64?  Does that
make our mod_php feature incomplete because it doesn't support Windows?  Is
Swoole incomplete because it only supports Linux and Mac?  It's not unusual
for complicated pieces of software to first be available for specific
subsets of platforms, and than gradually be ported to others.  It may not
be the intention, but it's difficult not to take calling it "incomplete" as
something other than disparaging the mind-boggling levels of effort that
went into it over the last 7 years.  Seriously, it's akin to someone
handing us a goose that lays golden eggs, for free, and us complaining that
they require these special weeds to feed on.

You are pushing PHP towards a future where
> there is effectively a single contributor, possibly two, able to make
> changes to Zend+Opcache; You are changing core parts of PHP too fast and
> making other contributors, including the maintainers of external tooling
> which the ecosystem requires to function, uncomfortable.
>

These are valid concerns, which is why they are fact covered in the RFC.
Of course, it would be possible to make changes to the engine/OPcache
without maintaining JIT - which would in turn break only JIT, in case we
reach a situation where JIT has no maintainers, or they're unable to keep
up with the changes.  The architecture is purposely designed in a way that
the engine remains independent of the JIT layer.

I really don't think you have bad intentions, but think our processes are
> allowing us to make questionable decisions for the whole project, and this
> I intend to resolve, regardless of your next actions, before any more
> questionable decisions can be taken.


I think there were questionable decisions that happened long before
FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
for them specifically.

I'm fine with waiting with the JIT vote until we figure out voting.  I
don't think we're in any rush as far as the decision is concerned (and we
can start discussing anyway).  I'm not fine with rushing to hastily change
the rules (while breaking the existing ones) to counter a specific RFC.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Thu, Jan 31, 2019 at 2:07 PM Zeev Suraski  wrote:

> >-Original Message-
> >From: Joe Watkins 
> >Sent: Thursday, January 31, 2019 2:59 PM
> >To: internals@lists.php.net
> >Subject: [PHP-DEV] RFC Abolish Narrow Margins
> >
> >Afternoon internals,
> >
> >Some time ago I brought up for discussion:
> >https://wiki.php.net/rfc/abolish-narrow-margins
> >
> >I intend to bring this up for vote in the next few days.
>
> Joe,
>
> Given that time that passed since I brought up my wider-scoped RFC, and
> yet haven't pushed it through (some major things were happening on my end,
> as you may have heard...) - I can imagine you're not going to like what I'm
> going to say, but fundamentally - nothing changed.  It still doesn't make
> sense, IMHO, to discuss the margin independently of other questions - even
> if you explicitly mention them as being outside of the scope of the RFC.
>
> Also, given the time that passed and the importance of this, it should
> require a brand new mandatory 2-week discussion period before we go for a
> vote - even if you insist on moving forward with this narrow-scoped RFC.
>
> At the same time, I'd like to finally solicit feedback explicitly on my
> wider-scoped RFC, as I guess we can't wait any longer.  I'll send a
> separate email about that.
>
> Zeev
>

I agree with Joe here that we should handle the question of voting margins
separately. Your RFC is a much more comprehensive reform, which contains a
number of points that look highly controversial to me (such as the eligible
voter changes). It may take a long time until we reach a satisfactory
consensus there.

On the other hand, this RFC is very simple and at least to me a complete
no-brainer. I already use 2/3 majority for all my votes, because I very
strongly believe that changes to PHP need to be held to a much higher
standard than a simple majority. It is outright shameful that functionality
can be added to PHP if 21 vote in favor and 20 against. That's not a
consensus, that's a complete disagreement.

It's not necessary to decide all questions regarding the RFC process at
once. Voting threshold is a very self-contained issue and we can decide it
separately from other controversial changes.

Regards,
Nikita

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

I'm going to use unambiguous and direct language to make sure my intentions
and concerns are communicated clearly, you can either receive this as a
personal attack, or as a contributor being direct, I would prefer the
latter.

Let us be clear about the things you are doing:

You pushed FFI into php-src on a simple majority, it had one user, was
incomplete (with leaks), and had zero justification for being included in
php-src - it didn't require any internal API's and can function just fine
as a PECL extension, still you pushed through with the RFC and it was
accepted on a simple majority.

You are now trying to push JIT into php-src on the same slim, clearly
unacceptable majority, and even if you change the majority requirements,
what's worse is you want to include it in a minor version. Once again, this
is an incomplete feature, failing to support the architectures we support
and declaring them unimportant. You are pushing PHP towards a future where
there is effectively a single contributor, possibly two, able to make
changes to Zend+Opcache; You are changing core parts of PHP too fast and
making other contributors, including the maintainers of external tooling
which the ecosystem requires to function, uncomfortable.

I really don't think you have bad intentions, but think our processes are
allowing us to make questionable decisions for the whole project, and this
I intend to resolve, regardless of your next actions, before any more
questionable decisions can be taken.

Cheers
Joe






On Thu, 31 Jan 2019 at 14:38, Zeev Suraski  wrote:

> Joe,
>
>
>
> First, you have to wait an absolute minimum of one week, and arguably two
> weeks, from the point in time you say you intend to move ahead with the RFC
> for a vote.  That’s per the ratified Voting RFC, this really isn’t up for
> the individual RFC author to decide.  It’s clear that an author can’t wake
> up a year after a certain discussion and move directly to a vote, even in
> the poorly written Voting RFC that’s currently in effect.  Given the far
> reaching implications of this particular RFC, it’s pretty clear that this
> shouldn’t be one of the short, 1-week ones, but I guess this is open for
> interpretation (yet another illness of the current Voting RFC that must be
> resolved).
>
>
>
> Re: JIT - I don’t think we should halt the discussion on the RFC, but I do
> think it should require a 2/3 majority – IFF we define the voting rights
> and other topics.  In other words – we can start discussing the merits and
> downsides of the RFC – but should probably wait with the vote itself until
> that’s cleared.
>
>
>
> For the record, I resent the language you used and the mal-intentions you
> attribute to me here.  I’ll leave it at that.
>
>
>
> Zeev
>
>
>
> *From:* Joe Watkins 
> *Sent:* Thursday, January 31, 2019 3:26 PM
> *To:* Zeev Suraski 
> *Cc:* internals@lists.php.net
> *Subject:* Re: [PHP-DEV] RFC Abolish Narrow Margins
>
>
>
> Afternoon Zeev,
>
>
>
> I imagine you will not like what I have to say either: In light of the
> recent actions you have taken and are taking to push incomplete software
> into php-src on narrow margins, prematurely, it makes perfect sense to
> discuss margins independently, and I intend to do so. Your opinion will be
> taken into consideration when you cast your vote.
>
>
>
> I do insist, and will not be waiting two weeks, unless you agree to delay
> the JIT RFC until this issue is resolved.
>
>
>
> Cheers
>
> Joe
>
>
>
>
>
>
>
> On Thu, 31 Jan 2019 at 14:07, Zeev Suraski  wrote:
>
> >-Original Message-
> >From: Joe Watkins 
> >Sent: Thursday, January 31, 2019 2:59 PM
> >To: internals@lists.php.net
> >Subject: [PHP-DEV] RFC Abolish Narrow Margins
> >
> >Afternoon internals,
> >
> >Some time ago I brought up for discussion:
> >https://wiki.php.net/rfc/abolish-narrow-margins
> >
> >I intend to bring this up for vote in the next few days.
>
> Joe,
>
> Given that time that passed since I brought up my wider-scoped RFC, and
> yet haven't pushed it through (some major things were happening on my end,
> as you may have heard...) - I can imagine you're not going to like what I'm
> going to say, but fundamentally - nothing changed.  It still doesn't make
> sense, IMHO, to discuss the margin independently of other questions - even
> if you explicitly mention them as being outside of the scope of the RFC.
>
> Also, given the time that passed and the importance of this, it should
> require a brand new mandatory 2-week discussion period before we go for a
> vote - even if you insist on moving forward with this narrow-scoped RFC.
>
> At the same time, I'd like to finally solicit feedback explicitly on my
> wider-scoped RFC, as I guess we can't wait any longer.  I'll send a
> separate email about that.
>
> Zeev
>
>

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

[Zeev Suraski]

On Thu, Jan 31, 2019 at 3:53 PM Kris Craig  wrote:

> I think you may be over-reaching a bit on the eligible voters part.  Keep
> in mind that all those who would be affected would still be able to vote on
> this RFC.  I think it's too restrictive on that part.
>

I realized that this part of the RFC is likely to be challenging.  I'm open
to additional ideas (or tweaking of existing ones) - but at the same time,
I think the current situation is not sustainable - nor can I think about
any other (large) Open Source project that employs anything similar.
Today, any person can become a voter, with identical rights to long time,
committed contributors - virtually overnight, with very little (or
virtually no) commitment on their part.  Open Source project governance
tends to be a meritocracy - and even this proposal sets a fairly low bar to
having the very same voting rights as Rasmus, me, Nikita or Dmitry.  Again,
I'm very open to ideas on how to improve on it, it's not an easy task to
tackle.

For the record, something like this *was* in fact the thinking behind the
language in https://wiki.php.net/rfc/voting - but much like other parts of
the RFC, it was poorly written, and in this case - even more poorly
implemented.

Also, why does FIG get special treatment?


The list can (and probably should) be amended;  The goal here is to bring
in additional, non-source-contributors to the mix that are at the same time
experienced PHP developers that can represent a large number of
developers.  PHP-FIG seemed to be a good fit for that bill, but there are
probably others that should be added as well.

Zeev

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

[Kris Craig]

I think you may be over-reaching a bit on the eligible voters part.  Keep
in mind that all those who would be affected would still be able to vote on
this RFC.  I think it's too restrictive on that part.

Also, why does FIG get special treatment?

--Kris


On Thu, Jan 31, 2019, 5:44 AM Zeev Suraski  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
>
>
>
>
>
>

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

[Zeev Suraski]

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] RFC Abolish Narrow Margins

[Zeev Suraski]

Joe,

First, you have to wait an absolute minimum of one week, and arguably two 
weeks, from the point in time you say you intend to move ahead with the RFC for 
a vote.  That’s per the ratified Voting RFC, this really isn’t up for the 
individual RFC author to decide.  It’s clear that an author can’t wake up a 
year after a certain discussion and move directly to a vote, even in the poorly 
written Voting RFC that’s currently in effect.  Given the far reaching 
implications of this particular RFC, it’s pretty clear that this shouldn’t be 
one of the short, 1-week ones, but I guess this is open for interpretation (yet 
another illness of the current Voting RFC that must be resolved).

Re: JIT - I don’t think we should halt the discussion on the RFC, but I do 
think it should require a 2/3 majority – IFF we define the voting rights and 
other topics.  In other words – we can start discussing the merits and 
downsides of the RFC – but should probably wait with the vote itself until 
that’s cleared.

For the record, I resent the language you used and the mal-intentions you 
attribute to me here.  I’ll leave it at that.

Zeev

From: Joe Watkins 
Sent: Thursday, January 31, 2019 3:26 PM
To: Zeev Suraski 
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins

Afternoon Zeev,

I imagine you will not like what I have to say either: In light of the recent 
actions you have taken and are taking to push incomplete software into php-src 
on narrow margins, prematurely, it makes perfect sense to discuss margins 
independently, and I intend to do so. Your opinion will be taken into 
consideration when you cast your vote.

I do insist, and will not be waiting two weeks, unless you agree to delay the 
JIT RFC until this issue is resolved.

Cheers
Joe



On Thu, 31 Jan 2019 at 14:07, Zeev Suraski 
mailto:z...@zend.com>> wrote:
>-Original Message-
>From: Joe Watkins mailto:krak...@gmail.com>>
>Sent: Thursday, January 31, 2019 2:59 PM
>To: internals@lists.php.net
>Subject: [PHP-DEV] RFC Abolish Narrow Margins
>
>Afternoon internals,
>
>Some time ago I brought up for discussion:
>https://wiki.php.net/rfc/abolish-narrow-margins
>
>I intend to bring this up for vote in the next few days.

Joe,

Given that time that passed since I brought up my wider-scoped RFC, and yet 
haven't pushed it through (some major things were happening on my end, as you 
may have heard...) - I can imagine you're not going to like what I'm going to 
say, but fundamentally - nothing changed.  It still doesn't make sense, IMHO, 
to discuss the margin independently of other questions - even if you explicitly 
mention them as being outside of the scope of the RFC.

Also, given the time that passed and the importance of this, it should require 
a brand new mandatory 2-week discussion period before we go for a vote - even 
if you insist on moving forward with this narrow-scoped RFC.

At the same time, I'd like to finally solicit feedback explicitly on my 
wider-scoped RFC, as I guess we can't wait any longer.  I'll send a separate 
email about that.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

I imagine you will not like what I have to say either: In light of the
recent actions you have taken and are taking to push incomplete software
into php-src on narrow margins, prematurely, it makes perfect sense to
discuss margins independently, and I intend to do so. Your opinion will be
taken into consideration when you cast your vote.

I do insist, and will not be waiting two weeks, unless you agree to delay
the JIT RFC until this issue is resolved.

Cheers
Joe



On Thu, 31 Jan 2019 at 14:07, Zeev Suraski  wrote:

> >-Original Message-
> >From: Joe Watkins 
> >Sent: Thursday, January 31, 2019 2:59 PM
> >To: internals@lists.php.net
> >Subject: [PHP-DEV] RFC Abolish Narrow Margins
> >
> >Afternoon internals,
> >
> >Some time ago I brought up for discussion:
> >https://wiki.php.net/rfc/abolish-narrow-margins
> >
> >I intend to bring this up for vote in the next few days.
>
> Joe,
>
> Given that time that passed since I brought up my wider-scoped RFC, and
> yet haven't pushed it through (some major things were happening on my end,
> as you may have heard...) - I can imagine you're not going to like what I'm
> going to say, but fundamentally - nothing changed.  It still doesn't make
> sense, IMHO, to discuss the margin independently of other questions - even
> if you explicitly mention them as being outside of the scope of the RFC.
>
> Also, given the time that passed and the importance of this, it should
> require a brand new mandatory 2-week discussion period before we go for a
> vote - even if you insist on moving forward with this narrow-scoped RFC.
>
> At the same time, I'd like to finally solicit feedback explicitly on my
> wider-scoped RFC, as I guess we can't wait any longer.  I'll send a
> separate email about that.
>
> Zeev
>
>

RE: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

>-Original Message-
>From: Joe Watkins  
>Sent: Thursday, January 31, 2019 2:59 PM
>To: internals@lists.php.net
>Subject: [PHP-DEV] RFC Abolish Narrow Margins
>
>Afternoon internals,
>
>Some time ago I brought up for discussion:
>https://wiki.php.net/rfc/abolish-narrow-margins
>
>I intend to bring this up for vote in the next few days.

Joe,

Given that time that passed since I brought up my wider-scoped RFC, and yet 
haven't pushed it through (some major things were happening on my end, as you 
may have heard...) - I can imagine you're not going to like what I'm going to 
say, but fundamentally - nothing changed.  It still doesn't make sense, IMHO, 
to discuss the margin independently of other questions - even if you explicitly 
mention them as being outside of the scope of the RFC.

Also, given the time that passed and the importance of this, it should require 
a brand new mandatory 2-week discussion period before we go for a vote - even 
if you insist on moving forward with this narrow-scoped RFC.

At the same time, I'd like to finally solicit feedback explicitly on my 
wider-scoped RFC, as I guess we can't wait any longer.  I'll send a separate 
email about that.

Zeev

[PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon internals,

Some time ago I brought up for discussion:
https://wiki.php.net/rfc/abolish-narrow-margins

I intend to bring this up for vote in the next few days.

Cheers
Joe

[PHP-DEV] RFC: Abolish Narrow Margins

[Joe Watkins]

Afternoon internals,

Some time ago I brought up for discussion:
https://wiki.php.net/rfc/abolish-narrow-margins

I intend to bring this up for vote in the next few days.

Cheers
Joe

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

[Rowan Collins]

On Thu, 31 Jan 2019 at 10:53, Benjamin Morel 
wrote:

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

I agree, it probably doesn't help the community; but it happens, both in
open source projects, and in the many private code bases which are written
in PHP. The more breaking changes we make in the language, the *more*
likely it is that people will stay on old versions, where their code works
without modification, and have a negative opinion of upgrades.



> 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 problem comes if the share using the old names *doesn't* decline enough
(and how would we even know?). 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.

To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they *want* to upgrade their code to use it, although it takes
us close to "completely new language" territory.

If we can persuade every user of PHP that the change is bringing them a
real benefit to outweigh the cost of re-writing and re-learning, then we
can make grand changes to the language; I don't think moving underscores
around will ever do that.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] JIT

[Marcos Passos]

JIT, FFI, covariant return types and typed properties: what a year for PHP.

Thank you all for working on making PHP better and better.

- Marcos

Em qui, 31 de jan de 2019 às 08:54, Dmitry Stogov 
escreveu:

>
>
> On 1/31/19 1:15 PM, Albert Casademont wrote:
> > Hi all,
> >
> > This is fantastic news thank you! I was going to ask if JIT would also
> > work when Opcache is enabled with "opcache.file_cache_only".
>
> Unfortunately, not yet, but we are planning to move opcache into PHP-8
> core and allow optimization and JIT without caching.
>
> > Our use
> > case is a ReactPHP app that right now only has Opcache basically for the
> > optimizations and we do not use the standard shared memory portion. We
> > believe JIT could improve quite a lot these kinds of "long-running"
> > processes that can serve multiple requests per-process. Thanks a lot!
>
> Better to try and provide feedback right now.
> You can get sources and build PHP from the link in RFC.
> https://github.com/zendtech/php-src/
>
> Thanks. Dmitry.
>
> >
> > Best,
> >
> >
> >
> > 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.
> >
>

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

[Christoph M. Becker]

On 31.01.2019 at 08:34, Peter Kokot wrote:

> 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).
> 
> Not that it is not possible to do this, but too many people promote
> this state as not possible to change. I didn't put too much effort to
> make a list of all the changes to an extend as is nicely done in the
> RFC but maybe enough would be renaming functions and alias them
> properly from major/minor release version to version and furthermore
> deprecate the aliases, so they match the pattern suggested for PHP
> vanilla functions [2]. Not to mention really good ideas from the past
> discussions with namespacing functions and similar approaches...
> 
> But, yes... Without proper will or motivation from key people who
> could change this it will stay in the inconsistent state and we all
> accept it as is. Specially in discussions about a major release where
> BC could be done.
> 
> [1] https://wiki.php.net/rfc/consistent_function_names
> [2] https://github.com/php/php-src/blob/master/CODING_STANDARDS

In my opinion, there is no gain in renaming bcadd() to bc_add(), for
instance.  A namespaced variant BC\add() might be an improvement, but
likely it should rather be BCNumber::plus() (also overloading the +
operator).  See also the closely related discussion regarding renaming
the image functions: .

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 1/31/19 1:15 PM, Albert Casademont wrote:
> Hi all,
> 
> This is fantastic news thank you! I was going to ask if JIT would also 
> work when Opcache is enabled with "opcache.file_cache_only".

Unfortunately, not yet, but we are planning to move opcache into PHP-8 
core and allow optimization and JIT without caching.

> Our use 
> case is a ReactPHP app that right now only has Opcache basically for the 
> optimizations and we do not use the standard shared memory portion. We 
> believe JIT could improve quite a lot these kinds of "long-running" 
> processes that can serve multiple requests per-process. Thanks a lot!

Better to try and provide feedback right now.
You can get sources and build PHP from the link in RFC.
https://github.com/zendtech/php-src/

Thanks. Dmitry.

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

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

[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] Deprecation ideas for PHP 8

[Rowan Collins]

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] [RFC] JIT

[Benjamin Morel]

Just want to say that this is HUGE, thanks so much for the work done here,
can't wait to try it out, hopefully this will land in PHP 7.4!

Ben

On Thu, 31 Jan 2019 at 10:44, 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.
>

Re: [PHP-DEV] [RFC] JIT

[Albert Casademont]

Hi all,

This is fantastic news thank you! I was going to ask if JIT would also work
when Opcache is enabled with "opcache.file_cache_only". Our use case is a
ReactPHP app that right now only has Opcache basically for the
optimizations and we do not use the standard shared memory portion. We
believe JIT could improve quite a lot these kinds of "long-running"
processes that can serve multiple requests per-process. Thanks a lot!

Best,



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

[PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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.