Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

[Peter Kokot]

Hello,

On Wed, 6 Feb 2019 at 08:13, Mark Baker  wrote:
>
> Looking at the Voting Eligibility discussion going on at the moment.
>
> I, like many others, participated in the last testfest 18 months or so
> ago. Did the results from that ever get merged? Or have they simply been
> discarded or forgotten? If merged, they certainly don't show up in the
> contributions list posted aganst the Workflow and Voting RFC Eligibility
> list: yet all those who participated in the testfest care about the
> language enough to get involved

No, they didn't. And longer we wait more file differences and "merge"
conflicts will happen.

I'd suggest to start adding one by one those that are accepted and
confirmed [1].

I can help sort this mess. A separate fork out of the php/php-src was
not such a good idea.

Important thing is also that the author is recognised in the commit
log properly and credits section is added as a recognition for the
volunteers (as noted in the php test fest instructions and all).

Let me know when we start adding those. Have a nice day.

[1] https://github.com/phpcommunity/phptestfest-php-src/pulls


-- 
Peter Kokot

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

[PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

[Mark Baker]

Looking at the Voting Eligibility discussion going on at the moment.

I, like many others, participated in the last testfest 18 months or so 
ago. Did the results from that ever get merged? Or have they simply been 
discarded or forgotten? If merged, they certainly don't show up in the 
contributions list posted aganst the Workflow and Voting RFC Eligibility 
list: yet all those who participated in the testfest care about the 
language enough to get involved


-- 
Mark Baker


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


  I LOVE PHP

Re: [PHP-DEV] 回复： [PHP-DEV] New website for the PHP project

[Peter Kokot]

Hello,

On Wed, 6 Feb 2019 at 01:37, 苏晞 <2823324...@qq.com> wrote:
>
> What the hell are you fucking talk about ,beaches -- 原始邮件 
> --

If I'd run this mailing list, you'd get a several weeks to months mute
now. But luckily that's not the case.

Read the mailing list rules [1] please. The tone and the quality of it
that is sent to these public channels is what makes the discussion
atmosphere and also younger generations learn from such low quality
responses. Keep this in your mind before sending emails or messages.

Thank you.

[1] https://github.com/php/php-src/blob/master/README.MAILINGLIST_RULES

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

[Nicolas Grekas]

Hi Nikita


https://wiki.php.net/rfc/consistent_type_errors


Would it make sense and be possible to trigger a deprecation notice in PHP
7.4?

That might help the ecosystem move forward in a smooth way instead of
experimenting the failure when actually moving to 8.

Nicolas

Re: [PHP-DEV] [RFC] JIT

[Matthew Brown]

I’m not sure it’s a great real-world example - PHP Parser is much more maths-y 
than the vast amount of PHP code, but if your PHP-based compiler had a similar 
makeup it might show somewhat similar benefits.

> On Feb 5, 2019, at 8:47 PM, Andrea Faulds  wrote:
> 
> Hi,
> 
> Dmitry Stogov wrote:
>> I've added info from Nikita: PHP-Parser became 1.5 times faster.
> 
> That is actually a very good real-world example from my perspective and makes 
> a better case for why JIT compilation to native code would be beneficial. I 
> would like to write a PHP compiler in PHP (actually, I began doing so but 
> it's very neglected and pretty useless) and it is exciting if JIT could make 
> PHP do that type of task faster. :)
> 
> Thanks,
> Andrea
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

[Pierre Joye]

Good morning Zeev :)

Thanks you for this RFC. I think it is long due to get a status of
where we are, what we like to have and what we can improve. My
apologize for the long reply, and as I got a mention in this reply, I
felt the need to put my grain of salt in this discussion. I hope you
don't mind.

I am not sure it makes sense to have all in one RFC however I fully
agree that the time has come to know where we are and improve things.
I am trying to explain in this reply.

On Sun, Feb 3, 2019 at 1:19 PM Zeev Suraski  wrote:

> Fair enough, I've heard that question from several others.
>
> I'll use your email to clarify my motivation for the RFC, primarily on the
> voting eligibility part - in slightly more detail than my reply to Nikita
> on the other thread.

I think it would be better to clarify the RFC itself.


> Beginning with the latter, the reality of things that the Voting RFC of
> 2011 was written in what was supposed to codify, and also structure a bit
> more the already existing process of decision making that we had prior to
> it.  The structuring was mainly through the introduction of a voting
> process, as well as some elements such as a mandatory discussion period.

Exactly.

The goal was also to streamline the introduction of features and
ensure a fully transparent decision can be taken. Mainly initiated by
some core developers and led by Lukas and myself to bring the 1st
version of the RFC process to life. It was cruelly required after the
6.0 fiasco and the long periods of no releases (ended by 5.3 and with
5.4 being the first release under the new rules).

> However, it quickly became apparent that this RFC, that was written with a
> certain 'working knowledge' of what was already happening de-facto, and
> assuming these would continue - became treated as if it was the U.S.
> constitution, and whatever wasn't in it - did not exist.  Moreover - even
> elements which were in fact in it (such as the voting eligibility), became
> ignored - exclusively for the simple reason of the way the Wiki software,
> used for voting, was implemented.

I think it is a bit of an extreme comparison here. However some
strictness were required to actually get things done and stop the
(benevolent or not) dictatorship which has brought the core to its
knees, divisions and a very unhealthy environment on internals. This
were a very dark moment in PHP history. We have grown and I am so
happy to see that things have changed in so many ways since then
(thanks to all devs).


> Edge cases came up over the years in all sorts of manners.  The most recent
> edge case which isn't handled by the terse, laconic 2011 Voting RFC is the
> Abolishing Narrow Margins RFC, which went straight from de-facto
> hibernation into a "we're about to vote" stage overnight.  But there were
> many others (and yes, one of the common ones was 'how do we choose between
> 50%+1 and 2/3', but it was by no means the only one).

This one was supposed to be clear (I will leave to the reader to go
through the archives), ala, it was not so clear after all. The 2/3
were about everything affecting the language, the core part of it. An
extension f.e. was not thought to be part of the language. But almost
anything under /Zend, ext/standard, main/ or stream would (or
similar). Now with massive changes in how the web is developed,
something considered as a core critical feature 10 years ago is
totally useless now. We need to adapt.

What is core and what is an extension need to be clarified and I would
suggest to have a specific discussion about that. This discussion
could also include:

1. Definition of the core and what we want to include into it.

2. how we include and remove extensions

3. Do we want to always bundle all these extensions? as in. Should we
not focus on the core language and use distribution mechanisms for
anyone willing to add more exts. The extensions remaining should then
be considered as part of the core because of the critical need for PHP
as a language. Reflection, Xml, Json, reflection for example are very
good candidates. Databases extensions on the other hand make less
sense and should deserver their own releases cycles (which is
happening already anyway).

I am not sure if it makes sense to be in the same RFC. Maybe easier to
have a separate discussions about that as well. More discussions, but
smaller, clearer RFCs very crystal clear goals and expectations.

> The goal here is to
> provide clear cut answers to these cases, instead of leaving it up to the
> RFC author to decide.  Over the years, it became clear that RFC authors had
> not only the ability to decide what goes into the RFC, but to also decide
> much of the process surrounding the discussion and acceptance of the RFC -
> filling the major voids that were present in the terse 2011 Voting RFC on
> demand.
>
> In terms of Voting Eligibility, here's what was written in the original RFC:
>
> ---quote---
> There's no way around this 'small' issue. Changes made to 

Re: [PHP-DEV] Re: Don't silence fatal errors

[Zeev Suraski]

On Tue, Feb 5, 2019 at 7:19 PM Nikita Popov  wrote:

> On Tue, Feb 5, 2019 at 5:55 PM Zeev Suraski  wrote:
>
>> On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov  wrote:
>>
>>> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov 
>>> wrote:
>>>
>>>
>>> I'd like to move forward with this change. I think the overall reception
>>> here has been positive, although in the discussion some other
>>> possibilities
>>> that avoid/reduce the BC aspect have been discussed. I think now that we
>>> have a PHP 8 branch, it would make sense to apply this as-is. The BC
>>> break
>>> is quite minor (compared to the other changes in PHP 8) and I think this
>>> is
>>> the cleanest way to solve the problem, as it only changes the list of
>>> silences errors, without introducing any new error handling concepts or
>>> mechanisms.
>>
>>
>> I don't think that other changes that may or may not make it into PHP 8
>> should influence our decision -  BC breaks accumulate and the more you have
>> of them, the more difficult it is to migrate.  I'm also present unaware of
>> anything we already decided to 'break' in PHP 8 as of now (with the
>> exception of the removal of deprecated 7.x features).
>>
>> That said - I think we all agree the BC breakage scope is small - but at
>> the same time, it may be quite fatal for those that are affected.  Those
>> who have display_errors on (which is both horrible for production and at
>> the same time fairly popular) are risking exposing sensitive data that
>> beforehand, they were safely and explicitly hiding using @.
>>
>
> I can see the general concern here, but I'm having a hard time imagining
> that this will be an issue in practice. If you have display_errors=on you
> are at risk of leaking information in error messages with or without this
> change. The prime example of leaking information, which is passwords
> contained in the exception stack trace of a failed PDO connection, isn't
> even affected by this, because the silencing will be removed as part of
> exception unwinding anyway.
>
>
Well, there are all sorts of information leaks that can happen as a result
of this, including filesystem layout and even the fact that the server is
running PHP in the first place.

Is there any reason *not* to do it in such a way that provides a gentler
>> migration path?  Introduce a new error level that would be a part of E_ALL
>> in 7.4, but outside of E_ALL in 8.0 - that would govern whether fatal
>> errors are silenced or not.
>>
>
> The reason not to do it is pretty much the same as always: Adding that new
> error level is basically the same as adding a new ini setting (and if we do
> want that, then I think it should be it's own ini setting and not hacked in
> as part of error_reporting), and you know our usual opinion on that topic.
> Furthermore, in this particular case it would also defeat the purpose of
> the change. If we set the option such that fatals are silenced by default,
> then we may as well not make the change, because the people who benefit
> most from it (non-expert users) are not going to change that default.
> Conversely, if we do not silence fatals by default, then we don't solve the
> issue with display_errors=on you mentioned above (as it requires explicitly
> setting an option, in which case they could just set display_errors=off
> instead.)
>

While I don't really agree that adding a new error level is equivalent to
adding a new INI entry, and I would go for having it as a part of the error
levels and not as a separate INI entry if we were to add this functionality
- I think you're fundamentally right that this approach doesn't truly bring
value in making the migration smoother.  I can't really think of an elegant
way to handle this given the unique situation where this whole change is in
the context of error suppression - which means deprecation notices aren't
helpful.

As long as we have a prominent warning about this in our migration guide
alerting people to the associated risk in setups where display errors is on
- I can live with the change as-is.  How do we ensure that it doesn't get
lost in the clutter given that it has no RFC?

Zeev

Re: [PHP-DEV] [RFC] JIT

[Andrea Faulds]

Hi,

Dmitry Stogov wrote:



I've added info from Nikita: PHP-Parser became 1.5 times faster.



That is actually a very good real-world example from my perspective and 
makes a better case for why JIT compilation to native code would be 
beneficial. I would like to write a PHP compiler in PHP (actually, I 
began doing so but it's very neglected and pretty useless) and it is 
exciting if JIT could make PHP do that type of task faster. :)


Thanks,
Andrea

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

[PHP-DEV] ?????? [PHP-DEV] New website for the PHP project

[????]

What the hell are you fucking talk about ,beaches --  
--
??: "Midori Koak"
: 2019??2??6??(??) 3:49
??: "Levi Morrison";"azjezz";
: 
"internals@lists.php.net";"php-webmas...@lists.php.net";
: Re: [PHP-DEV] New website for the PHP project


I can do some design, I designed the UI of CakePHP framework generators in 
2015. You can see the whole process here: 
https://github.com/cakephp/cakephp/issues/6679

We should not rely on any css, js or html framework in my opinion. But it's up 
to you.

For layout, CSS Grid and Flexbox is more than enough and would be future proof, 
but should be tested and polyfilled.

A lot of cross browser testing will be needed.

Cheers,
Midori

On 04/02/2019, 02:03, "Levi Morrison"  wrote:

On Sun, Feb 3, 2019 at 5:15 PM azjezz  wrote:
>
> Hello Internals !
>
> As @official_php suggested [1], I'm here to propose a new website for the 
PHP Project.
>
> In my opinion, current design looks old, outdated and bland. This sadly 
may reflect "badly" on the language
>
> reputation nowadays.
>
> New comers find it hard to go around the website, to write "comments", 
report issues or write RFCs.
>
> Even signing up for the internals mailing list wasn't an easy task [2].
>
> Since the development of PHP 8.0 has started, I think its a good idea to 
start working on a new website.
>
> # Global proposal
>
> The proposal here is to do a major rewrite of the PHP sites. This rewrite 
would includes php.net, windows.php.net,
>
> bug.php.net, wiki.php.net, qa.php.net and other official php websites.
>
> It would be done with this in mind:
>
> * No PHP framework (to avoid favoriting one)
>
> * Keep it simple: little to no changes to the database structures
>
> * This site should look modern, simple and feel welcoming.
>
> * A new home page, not a "news" page, but a page simply showing the PHP 
Logo, a code example maybe and
>
> the download link [3].
>
> * A new community website [4], it can be a place for people to ask 
questions and discuss php in general - no one uses IRC anymore.
>
> * Single account: Users should be able to use the same community account 
to file bugs, create a new RFC (depending on karma) and leave notes on the 
documentation.
>
> * Ideally all *.php.net websites would be "merged" into a single brand 
new website, but I'm not sure about the hosting
>
> specificities (eg, what server does what).
>
> # FrontEnd Framework
>
> We don't need that too, but we can use one ! there's some light-weight 
options out there.
>
> but i'm pretty sure some people in the php community have experience with 
front-end development and will happily contribute.
>
> see :
>
> - https://mustard-ui.com/
>
> - https://getuikit.com/
>
> - https://bulma.io/
>
> - https://picturepan2.github.io/spectre/index.html
>
> # Next steps
>
> I would really like to hear opinions about this proposal.
>
> [1] https://twitter.com/official_php/status/1091903415377108994
>
> [2] https://twitter.com/SaraMG/status/1092185205572542466
>
> [3] 
https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
>
> [4] https://php.net/community
>
> ---
>
> Saif Eddin Gmati 

I appreciate the enthusiasm. If you think the current PHP website is
old, out-dated, and bland, you must have not experienced the previous
one:

  
https://i2.wp.com/www.geekgumbo.com/wp-content/uploads/2012/01/phpsite45.png

In any case, I hope you realize this is an ambitious project. It will
take a very long time to build a cohesive UI, and then also a very
long time to update the bugs, windows, docs, wiki, etc, websites to
use it. If you are seriously committed to this, then the next step is
to create mock-ups for every type of page across PHP.net that you can
find, and to share them on the PHP Webmasters mailing list (which I've
cc'd). Then, we'll probably give you a few more pages that needs
mocks, after which you will then have to attempt to build the mock-ups
in a few different codebases.

I did the last redesign, and I took a less rigorous approach. If I
were to do it again, I would be much more rigorous in gathering
requirements and building mock-ups. There were a lot of pages which
needed re-worked because of my design, which took even more time.
While it's okay for some pages to be re-worked content-wise to fit the
new design, you want to minimize it.

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



-- 
PHP 

[PHP-DEV] Re: [RFC] Consistent type errors for internal functions

[Andrea Faulds]

Hi Nikita,

Nikita Popov wrote:

I'd like to bring forward the following proposal for PHP 8, which will make
(zpp) parameter parsing failures always result in a TypeError (rather than
generating a warning+null, depending on circumstances):

https://wiki.php.net/rfc/consistent_type_errors


I like this proposal. IMO PHP's E_WARNING + NULL is the worst of its 
“Keep Calm and Carry On” (sorry) behaviours, it would be nice to get rid 
of it for good, rather than just in the comfy world of strict_types=1.



The goal here is to remove one of the inconsistencies between user-defined
and internal functions, and to put us in a position where we can actually
start specifying type information in arginfo without fear of breaking
things.


Regrettably, as I pointed out to you via another channel, that idea also 
faces the problem of the other deliberate inconsistency I am responsible 
for in userland scalar type declarations, namely that the non-nullable 
variety of those reject null as a valid value, unlike internal functions 
which will happily coerce it. It's funny to mention this here, as the 
E_WARNING + NULL behaviour your RFC would drop was a primary 
justification of mine for making NULL special here. Unfortunately it's 
not the only case, I'm sure uncountably much PHP code relies on things 
like strlen($_GET['nonexistent']) working… but I digress.


Thanks,
Andrea

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Tuesday, February 5, 2019 8:51 PM, Rowan Collins  
wrote:

> On 05/02/2019 17:32, Tom Worster wrote:
>
> > I have two suggestions, assuming you proceed roughly as outlined in
> > your original post.
> >
> > 1.  Start with /community
> >
> > > A new community website [4], it can be a place for people to ask
> > > questions and discuss php in general - no one uses IRC anymore.
>
> Like all the bold ideas in this thread, that alone would need some
> serious planning and commitment.
>
> Technically, it's easy - assuming you'd just install PHPBB / Gitter /
> whatever, and not try to invent yet another wheel; but building a
> community is hard.
>
> For a start, off the top of my head, you would need to figure out:
>
> -   Who is this community aimed at, and how will you attract them to use it?
> -   Who will moderate it, and according to what policies? (Particularly
> important if you're branding it as "the official PHP community")
>
> -   How will it relate to all the existing community tools (IRC,
> StackOverflow Chat, phpug.slack.com, these mailing lists, etc, etc)?
>
> If you can make it successful, I'm sure it would be a great asset, but
> there's a long and uncertain road between here and there.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Webmaster List Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

You are totally right.

in my opinion the the community site should be targeted to all the PHP 
Community ( PHP Developer / Core Developers ) to ask questions about PHP, 
discuss the development of PHP and related topics.

Moderation should be done by a Community Manager and Moderators. ( no idea for 
now who these would be, people we vote for or promoted by core members maybe ? )

For the software i would like to suggest https://flarum.org as well.

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

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[azjezz]

On Tuesday, February 5, 2019 8:49 PM, Midori Koçak  wrote:

> I can do some design, I designed the UI of CakePHP framework generators in 
> 2015. You can see the whole process here: 
> https://github.com/cakephp/cakephp/issues/6679
>
> We should not rely on any css, js or html framework in my opinion. But it's 
> up to you.
>
> For layout, CSS Grid and Flexbox is more than enough and would be future 
> proof, but should be tested and polyfilled.
>
> A lot of cross browser testing will be needed.
>
> Cheers,
> Midori

I'd really appreciate help in this.

if you would like to collaborate in the mock-ups for now, that would be great.

I'm not good enough with CSS so i have used Specter CSS framework in the 
mock-ups, it a lightweight pure CSS framework as i don't see the need for any 
JS yet.

I have sent you an invitation on GitHub, if you would like to join you are 
welcome.

https://github.com/azjezz/web-php-mock-ups/invitations

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

[PHP-DEV] Re: RFCs "under discussion"

[Christoph M. Becker]

On 05.02.2019 at 18:51, Stanislav Malyshev wrote:

>> “Inactive”[1] is likely what you're looking for.
> 
> Inactive implies it's not being worked on... But we certainly could move
> there at least ones that are "in discussion" for 2 years.

The description of the section is “This section is for RFCs that have
been deferred, obsoleted, or appear to have been abandoned. Sorry if
your RFC is added here and you feel it is still active; please move it
back to the appropriate section.”

If the description is wrong, it should be fixed.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] New website for the PHP project

[Rowan Collins]

On 05/02/2019 17:32, Tom Worster wrote:
I have two suggestions, assuming you proceed roughly as outlined in 
your original post.


1. Start with /community

A new community website [4], it can be a place for people to ask 
questions and discuss php in general - no one uses IRC anymore.



Like all the bold ideas in this thread, that alone would need some 
serious planning and commitment.


Technically, it's easy - assuming you'd just install PHPBB / Gitter / 
whatever, and not try to invent yet another wheel; but building a 
*community* is hard.


For a start, off the top of my head, you would need to figure out:

* Who is this community aimed at, and how will you attract them to use it?
* Who will moderate it, and according to what policies? (Particularly 
important if you're branding it as "the official PHP community")
* How will it relate to all the existing community tools (IRC, 
StackOverflow Chat, phpug.slack.com, these mailing lists, etc, etc)?


If you can make it successful, I'm sure it would be a great asset, but 
there's a long and uncertain road between here and there.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] New website for the PHP project

[Midori Koçak]

I can do some design, I designed the UI of CakePHP framework generators in 
2015. You can see the whole process here: 
https://github.com/cakephp/cakephp/issues/6679

We should not rely on any css, js or html framework in my opinion. But it's up 
to you.

For layout, CSS Grid and Flexbox is more than enough and would be future proof, 
but should be tested and polyfilled.

A lot of cross browser testing will be needed.

Cheers,
Midori

On 04/02/2019, 02:03, "Levi Morrison"  wrote:

On Sun, Feb 3, 2019 at 5:15 PM azjezz  wrote:
>
> Hello Internals !
>
> As @official_php suggested [1], I'm here to propose a new website for the 
PHP Project.
>
> In my opinion, current design looks old, outdated and bland. This sadly 
may reflect "badly" on the language
>
> reputation nowadays.
>
> New comers find it hard to go around the website, to write "comments", 
report issues or write RFCs.
>
> Even signing up for the internals mailing list wasn't an easy task [2].
>
> Since the development of PHP 8.0 has started, I think its a good idea to 
start working on a new website.
>
> # Global proposal
>
> The proposal here is to do a major rewrite of the PHP sites. This rewrite 
would includes php.net, windows.php.net,
>
> bug.php.net, wiki.php.net, qa.php.net and other official php websites.
>
> It would be done with this in mind:
>
> * No PHP framework (to avoid favoriting one)
>
> * Keep it simple: little to no changes to the database structures
>
> * This site should look modern, simple and feel welcoming.
>
> * A new home page, not a "news" page, but a page simply showing the PHP 
Logo, a code example maybe and
>
> the download link [3].
>
> * A new community website [4], it can be a place for people to ask 
questions and discuss php in general - no one uses IRC anymore.
>
> * Single account: Users should be able to use the same community account 
to file bugs, create a new RFC (depending on karma) and leave notes on the 
documentation.
>
> * Ideally all *.php.net websites would be "merged" into a single brand 
new website, but I'm not sure about the hosting
>
> specificities (eg, what server does what).
>
> # FrontEnd Framework
>
> We don't need that too, but we can use one ! there's some light-weight 
options out there.
>
> but i'm pretty sure some people in the php community have experience with 
front-end development and will happily contribute.
>
> see :
>
> - https://mustard-ui.com/
>
> - https://getuikit.com/
>
> - https://bulma.io/
>
> - https://picturepan2.github.io/spectre/index.html
>
> # Next steps
>
> I would really like to hear opinions about this proposal.
>
> [1] https://twitter.com/official_php/status/1091903415377108994
>
> [2] https://twitter.com/SaraMG/status/1092185205572542466
>
> [3] 
https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
>
> [4] https://php.net/community
>
> ---
>
> Saif Eddin Gmati 

I appreciate the enthusiasm. If you think the current PHP website is
old, out-dated, and bland, you must have not experienced the previous
one:

  
https://i2.wp.com/www.geekgumbo.com/wp-content/uploads/2012/01/phpsite45.png

In any case, I hope you realize this is an ambitious project. It will
take a very long time to build a cohesive UI, and then also a very
long time to update the bugs, windows, docs, wiki, etc, websites to
use it. If you are seriously committed to this, then the next step is
to create mock-ups for every type of page across PHP.net that you can
find, and to share them on the PHP Webmasters mailing list (which I've
cc'd). Then, we'll probably give you a few more pages that needs
mocks, after which you will then have to attempt to build the mock-ups
in a few different codebases.

I did the last redesign, and I took a less rigorous approach. If I
were to do it again, I would be much more rigorous in gathering
requirements and building mock-ups. There were a lot of pages which
needed re-worked because of my design, which took even more time.
While it's okay for some pages to be re-worked content-wise to fit the
new design, you want to minimize it.

-- 
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 tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller :
> Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] [RFC] JIT

[Niklas Keller]

> > Can you give some information on if there are pre-conditions that
> > must hold for a function to be jitted, or quit conditions that force
> > the JIT to be reverted for a function?
>
> -dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
> tag. It's possible to extend this manual control.

Shouldn't we introduce annotations instead of relying on doc comments?

Regards, Niklas

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

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Rowan Collins]

On Tue, 5 Feb 2019 at 17:25, Craig Duncan  wrote:

> The *iterable* type accepts a plain array, but not an object that is used
> to represent a plain array, that's surprising to me.
>


I think this notion of stdClass as "an object used to represent a plain
array" is a peculiar one. The only reason I can think of for using stdClass
is to specifically *not* be like an array in some way.

As I mentioned in the discussion thread, the closer comparison would be to
an anonymous class: $foo = new stdClass; and $foo = new class {}; both
produce objects with no behaviour, no pre-defined methods, and the ability
to define properties dynamically.

On that definition, there's no surprise at all: it's an object that has no
defined behaviour, so is not defined as having the "iterable" behaviour.



> To me, this class is presented as a first class citizen, but it works like
> a second class one.
>


While I agree that it's an anomaly in many ways, I think the fact that it's
not marked iterable is a peculiar detail to get stuck on.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] RFCs "under discussion"

[Rowan Collins]

On Tue, 5 Feb 2019 at 17:40, Stanislav Malyshev  wrote:

> Hi!
>
> Looking at our RFC page, we have over 50 RFCs under discussion. This is
> obviously not true - and can not be true, really, it's impossible to
> properly discuss 50+ RFCs at a time, and indeed most of these aren't
> being currently discussed. I propose to clean up that section and move
> RFCs for which there is no active discussion for, say, the last month,
> to separate status. "In Draft" status seem to suggest RFCs that have not
> yet been announced, so we need some other status for RFCs that have been
> announced but not being actively discussed. "Work in Progress" maybe?
>


A big +1 from me.

I suggested something similar in passing a few months ago, when I talked
about "sleeping RFCs" being revived at the last minute before a release
deadline: https://externals.io/message/102708#102729

I'll leave to other threads whether we should have a formal process for
when to transition RFCs into and out of "Dormant" status, but I see no
reason we can't, right now, move anything with no mailing list hits for 3
months, or even 2 months.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] RFCs "under discussion"

[Niklas Keller]

Am Di., 5. Feb. 2019 um 18:40 Uhr schrieb Stanislav Malyshev
:
>
> Hi!
>
> Looking at our RFC page, we have over 50 RFCs under discussion. This is
> obviously not true - and can not be true, really, it's impossible to
> properly discuss 50+ RFCs at a time, and indeed most of these aren't
> being currently discussed. I propose to clean up that section and move
> RFCs for which there is no active discussion for, say, the last month,
> to separate status. "In Draft" status seem to suggest RFCs that have not
> yet been announced, so we need some other status for RFCs that have been
> announced but not being actively discussed. "Work in Progress" maybe?

I think it's fine moving them back to "In Draft".

Regards, Niklas

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

[PHP-DEV] Re: RFCs "under discussion"

[Stanislav Malyshev]

Hi!

> “Inactive”[1] is likely what you're looking for.

Inactive implies it's not being worked on... But we certainly could move
there at least ones that are "in discussion" for 2 years.

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

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

[PHP-DEV] Re: RFCs "under discussion"

[Christoph M. Becker]

On 05.02.2019 at 18:40, Stanislav Malyshev wrote:

> Looking at our RFC page, we have over 50 RFCs under discussion. This is
> obviously not true - and can not be true, really, it's impossible to
> properly discuss 50+ RFCs at a time, and indeed most of these aren't
> being currently discussed. I propose to clean up that section and move
> RFCs for which there is no active discussion for, say, the last month,
> to separate status. "In Draft" status seem to suggest RFCs that have not
> yet been announced, so we need some other status for RFCs that have been
> announced but not being actively discussed. "Work in Progress" maybe?

“Inactive”[1] is likely what you're looking for.

[1] 

-- 
Christoph M. Becker

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

[PHP-DEV] RFCs "under discussion"

[Stanislav Malyshev]

Hi!

Looking at our RFC page, we have over 50 RFCs under discussion. This is
obviously not true - and can not be true, really, it's impossible to
properly discuss 50+ RFCs at a time, and indeed most of these aren't
being currently discussed. I propose to clean up that section and move
RFCs for which there is no active discussion for, say, the last month,
to separate status. "In Draft" status seem to suggest RFCs that have not
yet been announced, so we need some other status for RFCs that have been
announced but not being actively discussed. "Work in Progress" maybe?

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] New website for the PHP project

[Tom Worster]

I have two suggestions, assuming you proceed roughly as outlined in your 
original post.


1. Start with /community

A new community website [4], it can be a place for people to ask 
questions and discuss php in general - no one uses IRC anymore.


and use it to build and coordinate the dev team for this new php.net 
website. If you do a good job and the conversations and culture develop 
nicely then the scope of topics can expand as you already planned. It 
could be a success, providing something I think PHP needs, even if you 
don't reach all the other goals in your project.


2. Don't use a frontend framework. There's so little stability in this 
area that you should plan to own long-term maintenance of whatever you 
use, so it's better to start with your own, picking the ideas you like 
from the work of others.

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[azjezz]

> Is this your desired look you wanna propose? I may misunderstand and

this is the original proposal :
> https://twitter.com/azjezz/status/1091722433424285698

how ever people seem to lean more toward having releases and changlogs in the 
front-page.


> -   example code (with an option to run)
i have already explored more sites for programming languages and most do have 
code samples and `run` option, but people seem to dislike this idea here.

> -   short description
> -   get started
> -   latest versions
i already added these in the last changes : 
https://github.com/azjezz/web-php-mock-ups#landing


> -   example code (with an option to run)
> -   features
> -   why this lang and what especially for
> -   some latest news (not few pages as it is right now)
> -   etc.

i don't see how can we fit all this in 1 page.

but i think we can show releases in the sidebar + a button to read more ( see 
changelogs, download links .. etc ) / code sample in the main container / 
features and why this lang under it, and few news cards under with a link to 
/news.

if you have any other ideas please let me know or if you wanna send a PR that 
would be amazing :)

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

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Craig Duncan]

On Tue, 5 Feb 2019 at 16:39, Levi Morrison  wrote:

> I just wanted to pipe in to suggest an alternative approach to
> accomplish some of the same goals: an external PropertyIterator.
>

I believe Nikita suggested something similar, and while it would certainly
be useful it doesn't accomplish the same goals as this proposal.
The goal of this proposal is to make the language more consistent and less
surprising.
The *iterable* type accepts a plain array, but not an object that is used
to represent a plain array, that's surprising to me.

*stdClass* is "promoted" as part of the language, it's use is not advised
against anywhere in the manual, and it's the default response format for
*json_decode()*
To me, this class is presented as a first class citizen, but it works like
a second class one.

As it looks like my first approach to resolving this inconsistency is
likely to fail the vote, I'm considering a second approach now to update
the docs and "officially" deprecate/discourage usage of *stdClass*

Re: [PHP-DEV] Re: Don't silence fatal errors

[Nikita Popov]

On Tue, Feb 5, 2019 at 5:55 PM Zeev Suraski  wrote:

> On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov  wrote:
>
>> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov 
>> wrote:
>>
>>
>> I'd like to move forward with this change. I think the overall reception
>> here has been positive, although in the discussion some other
>> possibilities
>> that avoid/reduce the BC aspect have been discussed. I think now that we
>> have a PHP 8 branch, it would make sense to apply this as-is. The BC break
>> is quite minor (compared to the other changes in PHP 8) and I think this
>> is
>> the cleanest way to solve the problem, as it only changes the list of
>> silences errors, without introducing any new error handling concepts or
>> mechanisms.
>
>
> I don't think that other changes that may or may not make it into PHP 8
> should influence our decision -  BC breaks accumulate and the more you have
> of them, the more difficult it is to migrate.  I'm also present unaware of
> anything we already decided to 'break' in PHP 8 as of now (with the
> exception of the removal of deprecated 7.x features).
>
> That said - I think we all agree the BC breakage scope is small - but at
> the same time, it may be quite fatal for those that are affected.  Those
> who have display_errors on (which is both horrible for production and at
> the same time fairly popular) are risking exposing sensitive data that
> beforehand, they were safely and explicitly hiding using @.
>

I can see the general concern here, but I'm having a hard time imagining
that this will be an issue in practice. If you have display_errors=on you
are at risk of leaking information in error messages with or without this
change. The prime example of leaking information, which is passwords
contained in the exception stack trace of a failed PDO connection, isn't
even affected by this, because the silencing will be removed as part of
exception unwinding anyway.


> Is there any reason *not* to do it in such a way that provides a gentler
> migration path?  Introduce a new error level that would be a part of E_ALL
> in 7.4, but outside of E_ALL in 8.0 - that would govern whether fatal
> errors are silenced or not.
>

The reason not to do it is pretty much the same as always: Adding that new
error level is basically the same as adding a new ini setting (and if we do
want that, then I think it should be it's own ini setting and not hacked in
as part of error_reporting), and you know our usual opinion on that topic.
Furthermore, in this particular case it would also defeat the purpose of
the change. If we set the option such that fatals are silenced by default,
then we may as well not make the change, because the people who benefit
most from it (non-expert users) are not going to change that default.
Conversely, if we do not silence fatals by default, then we don't solve the
issue with display_errors=on you mentioned above (as it requires explicitly
setting an option, in which case they could just set display_errors=off
instead.)

Nikita

Re: [PHP-DEV] [RFC] JIT

[Bruce Weirdan]

On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  wrote:
> > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%)
> > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
> > -dopcache.jit=1201): 29.95s (92.7%)
>
> It may be interesting to try -dopcache.jit=1235. It should JIT only hot
> functions and requires some warm-up.

For this use case 1201 was the fastest of all the options I tried
(including 1235).

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

Re: [PHP-DEV] Re: Don't silence fatal errors

[Zeev Suraski]

On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov  wrote:

> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov 
> wrote:
>
>
> I'd like to move forward with this change. I think the overall reception
> here has been positive, although in the discussion some other possibilities
> that avoid/reduce the BC aspect have been discussed. I think now that we
> have a PHP 8 branch, it would make sense to apply this as-is. The BC break
> is quite minor (compared to the other changes in PHP 8) and I think this is
> the cleanest way to solve the problem, as it only changes the list of
> silences errors, without introducing any new error handling concepts or
> mechanisms.


I don't think that other changes that may or may not make it into PHP 8
should influence our decision -  BC breaks accumulate and the more you have
of them, the more difficult it is to migrate.  I'm also present unaware of
anything we already decided to 'break' in PHP 8 as of now (with the
exception of the removal of deprecated 7.x features).

That said - I think we all agree the BC breakage scope is small - but at
the same time, it may be quite fatal for those that are affected.  Those
who have display_errors on (which is both horrible for production and at
the same time fairly popular) are risking exposing sensitive data that
beforehand, they were safely and explicitly hiding using @.

Is there any reason *not* to do it in such a way that provides a gentler
migration path?  Introduce a new error level that would be a part of E_ALL
in 7.4, but outside of E_ALL in 8.0 - that would govern whether fatal
errors are silenced or not.

Zeev

Re: [PHP-DEV] RFC Weakrefs

[Rowan Collins]

On Tue, 5 Feb 2019 at 16:06, Dennis Birkholz 
wrote:

> Maybe for PHP 8 we
> will decide to require all classes to be serializable except classes
> that implement the Unserializable interface or something... Or the magic
> __isSerializable() method that can decide this at runtime for the actual
> state of an object without failing hard when trying it.
>


I agree, it can be very confusing if you have something like a SimpleXML
object buried somewhere, and your serialize() call blows up. (See the
example I've raised a couple of times where Exceptions may or may not be
serializable, because they slurp up objects from everywhere in their
backtrace.)

I was going to suggest this would fit with the discussion Nikita raised
about adding a new serialization mechanism, but thinking about it more, I'm
not sure how the API for this would work. If you don't recursively check
that the properties of an object are also serializable, the call is
useless; but if you do, it's really no different from try {
serialize($foo); } catch {}

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Levi Morrison]

On Mon, Feb 4, 2019 at 11:58 AM Craig Duncan  wrote:
>
> Hi all,
>
> Following the discussion it's now time to vote on whether we make the
> stdClass iterable or not.
> https://wiki.php.net/rfc/iterable-stdclass
>
> Note that while there is an implementation available, the vote is only on
> whether stdClass should fulfil the Traversable interface or not.
> Nikita had some ideas on a different implementation that I'll revisit if
> the vote passes.
>
> Voting will end in two weeks on 2019-02-18
>
> Thanks to everybody that shared their opinion and raised concerns during
> the discussion.
>
> Craig

I just wanted to pipe in to suggest an alternative approach to
accomplish some of the same goals: an external PropertyIterator.

  - It could allow us to refine which property visibilities we care to
iterate over. For instance, if we are in a protected or private
context we may want to still only iterate over public properties.
  - I think that with typed properties we will see more data-only
classes which would benefit from an external PropertyIterator.

Of course, that still means `stdClass` isn't automatically `iterable`,
but if you want it to be then you can pass in a PropertyIterator
instead.

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

Re: [PHP-DEV] RFC Weakrefs

[Girgias]

On Tue, 5 Feb 2019 at 17:06, Dennis Birkholz 
wrote:

> So I would really prefer the WeakReference class would just be
> serializable with all the consequences you outlined. Maybe for PHP 8 we
> will decide to require all classes to be serializable except classes
> that implement the Unserializable interface or something... Or the magic
> __isSerializable() method that can decide this at runtime for the actual
> state of an object without failing hard when trying it.
>
> Greets
> Dennis
>

That on its own would need an RFC AFAIK and I'm not really a fan of this
hypothetical change.
Also it feels kind of backwards imho. Why should I specify that something
is NOT serializable
when serialisation is a behaviour that usually needs special care with?

Also what would happen when someone does the typical thing to prevent
serialization:
public function __sleep() { throw new Exception(); }

Best regards

George P. Banyard

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

[Zeev Suraski]

On Tue, Feb 5, 2019 at 6:02 PM Côme Chilliet  wrote:

> Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit :
> > We'll have to agree to disagree on this one.  I would say that the way
> > virtually every other major Open Source project serves as a fairly good
> > proof point for my position.  In fact, even with the new eligible voting
> > criteria, we'd be well ahead of most other major OS projects in terms of
> > the number of people included in the process with full equal voting
> rights.
>
> I do not understand what this proves.
>

I'm not sure how I can deliver the point I was making in a better way than
I already did.  The gap in the way you and I perceive the way OS project
governance should work is too big for this to be a fruitful discussion - so
as I said from in the beginning, let's just agree to disagree.

Zeev

Re: [PHP-DEV] RFC Weakrefs

[Dennis Birkholz]

Hi Nikita,

On 05.02.19 16:50, Nikita Popov wrote:
Serialization for weak refs is a bit tricky, and I feel like supporting 
it could easily become a foot-gun. The fundamental problem is that for 
serialization to produce a meaningful value, the object referenced by a 
WeakReference must also be part of the serialized object graph as a 
strong reference somewhere. Otherwise, the WeakReference will 
immediately turn into a dud when unserialization ends, because the 
object it references is no longer live.


I think from a technical perspective, supporting serialization should be 
possible and not overly hard, it's more a question of whether we want 
to. As another data point, Java does not support serialization for 
WeakReference.


my fundamental problem here is that you can not reliably find out if 
something can be serialized or not. Each class that is not serializable 
by documentation/implementation but does not provide some programatical 
way of checking this adds another burden to create a special case for 
that class.


So I would really prefer the WeakReference class would just be 
serializable with all the consequences you outlined. Maybe for PHP 8 we 
will decide to require all classes to be serializable except classes 
that implement the Unserializable interface or something... Or the magic 
__isSerializable() method that can decide this at runtime for the actual 
state of an object without failing hard when trying it.


Greets
Dennis

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

[Côme Chilliet]

Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit :
> We'll have to agree to disagree on this one.  I would say that the way
> virtually every other major Open Source project serves as a fairly good
> proof point for my position.  In fact, even with the new eligible voting
> criteria, we'd be well ahead of most other major OS projects in terms of
> the number of people included in the process with full equal voting rights.

I do not understand what this proves.

«No other project is doing that» is not a strong enough argument towards not 
doing it.
What is the problem you are actually trying to solve? That some RFCs are not 
passing?

Côme

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

[Côme Chilliet]

Le mardi 5 février 2019, 02:38:50 CET Stanislav Malyshev a écrit :
> Hi!

Hi!

> Do you imagine Linus
> asking a vote of all Linux users about how to implement a kernel driver
> and implementing it only in a way that majority of Linux users approves?

Not sure that would be so bad. 
At least until it blocks everything and becomes a problem, but what I do not 
understand is that changing the RFC voters pool idea do not seem come from a 
problem with it, just some «These people are not writing C code, they should 
not vote» thinking.

> Because whoever makes the thing defines how the thing is made (of
> course, it takes more to make PHP than pure C coding, so I am bundling
> all contributors to the project - however widely defined - together). If
> you are to build a house, I am not going to tell you how to do it. It's
> your house, you build it however you want it - even if you might later
> invite me to visit. If I think the house is badly built, I may refuse to
> come, and criticize you, but I won't claim the power to tell you how to
> do it.

This is where we disagree, PHP devs are not building a house for themselves, 
they are building it for other people.

> Have a say, as in providing feedback and advice - sure, and they do.
> Having decisive voice, overriding the voice of people who actually
> implement it, in their own free time, and then give it away for free - no.

If I use my free time to make the language worse, that is not a good thing just 
because I did some work for free.

> > You make it like it’s a gift for people to be able to vote on PHP
> > RFCs while I feel like it’s good for PHP to have people voting its
> > RFCs.
> 
> There's no abstract "PHP" that it'd be good for beyond people who
> actually develop it. And I don't see how it'd be good for people who
> develop it to give control over how to develop it to people that don't.

I disagree here, PHP is supposed to be good to its community, not only its core 
developers.

> > One last point: Having non-core developers voting puts a higher bar
> > on RFC redacting quality: The author needs to explain his feature
> > well enough so that people without deep internal knowledge get it.
> 
> I don't see how the voting process prevents people that didn't get it
> from voting (either way). In a democracy, people do it all the time ;)
> So this is really not a solid argument for your point.

You may always have some random or misinformed vote but I do think you will get 
more vote if you successfully explains how your feature improve the situation.
When I do not understand at all what it’s about I usually don’t vote (for PHP 
RFCs I mean).

Côme


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

Re: [PHP-DEV] RFC Weakrefs

[Nikita Popov]

On Tue, Feb 5, 2019 at 4:11 PM Dennis Birkholz 
wrote:

> Hi Joe,
>
> On 02.02.19 09:35, Joe Watkins wrote:
> > Some time ago I brought this up for discussion, and last night was
> reminded
> > of it's existence, and so this morning rebased and reworked the patch a
> > little based on the feedback I got back then.
> >
> > Since it was long ago, and there's no particular rush, I don't intend to
> > open voting until the current policy adjustment RFC's are resolved, but
> > wanted to give everyone a heads up and ask for any feedback you may have
> at
> > this time.
>
> thanks for proposing to bring weak references into core, I myself would
> have needed them once or twice.
>
> One point from the RFC bothers me:
>
> > The proposed API:
> > - does not support serialization
>
> That is a really unfortunate decision, I would really like to have them
> serializable. Otherwise if you want to persist a weak ref you always
> have to convert them to a real ref before serialization and back
> afterwards. I would really like to have this transparency build in.
> Would be great if that could be added.
>

Serialization for weak refs is a bit tricky, and I feel like supporting it
could easily become a foot-gun. The fundamental problem is that for
serialization to produce a meaningful value, the object referenced by a
WeakReference must also be part of the serialized object graph as a strong
reference somewhere. Otherwise, the WeakReference will immediately turn
into a dud when unserialization ends, because the object it references is
no longer live.

I think from a technical perspective, supporting serialization should be
possible and not overly hard, it's more a question of whether we want to.
As another data point, Java does not support serialization for
WeakReference.

Nikita

[PHP-DEV] Re: Don't silence fatal errors

[Nikita Popov]

On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov  wrote:

> Hi internals,
>
> When the silencing operator @ is used, the intention is generally to
> silence expected warnings or notices. However, it currently also silences
> fatal errors. As fatal errors also abort request execution, the result will
> often be a hard to debug white screen of death.
>
> The most recent occurrence which motivated me to write this mail is
> https://bugs.php.net/bug.php?id=77205, but I've seen this play out
> multiple times already.
>
> I would like to propose to change the behavior of @ to only silence
> warnings, notices and other low-level diagnostics, but leave fatal errors
> intake. In particular, the following should not be silenced:
>
> * E_ERROR
> * E_CORE_ERROR
> * E_COMPILE_ERROR
> * E_USER_ERROR
> * E_RECOVERABLE_ERROR
> * E_PARSE
>
> This change would have two main implications for backwards compatibility:
>
> 1. Code that legitimately wants to silence fatal errors for whatever
> reason should now use error_reporting() (or ini_set()) to do so, instead of
> @.
>
> 2. Error handlers that want to only handle non-silenced errors may have to
> be adjusted. A common pattern I found in our own tests if checks for
> error_reporting() != 0 to detect silencing. This should be changed to
> error_reporting() & $err_no to detect whether the specific error type is
> silenced.
>
> A preliminary patch for this change is available at
> https://github.com/php/php-src/pull/3685.
>
> What do you think about this?
>
> Nikita
>

I'd like to move forward with this change. I think the overall reception
here has been positive, although in the discussion some other possibilities
that avoid/reduce the BC aspect have been discussed. I think now that we
have a PHP 8 branch, it would make sense to apply this as-is. The BC break
is quite minor (compared to the other changes in PHP 8) and I think this is
the cleanest way to solve the problem, as it only changes the list of
silences errors, without introducing any new error handling concepts or
mechanisms.

Nikita

Re: [PHP-DEV] RFC Weakrefs

[Dennis Birkholz]

Hi Joe,

On 02.02.19 09:35, Joe Watkins wrote:

Some time ago I brought this up for discussion, and last night was reminded
of it's existence, and so this morning rebased and reworked the patch a
little based on the feedback I got back then.

Since it was long ago, and there's no particular rush, I don't intend to
open voting until the current policy adjustment RFC's are resolved, but
wanted to give everyone a heads up and ask for any feedback you may have at
this time.


thanks for proposing to bring weak references into core, I myself would 
have needed them once or twice.


One point from the RFC bothers me:


The proposed API:
- does not support serialization


That is a really unfortunate decision, I would really like to have them 
serializable. Otherwise if you want to persist a weak ref you always 
have to convert them to a real ref before serialization and back 
afterwards. I would really like to have this transparency build in. 
Would be great if that could be added.


I am a little surprised how often the "is not serializable" label is put 
on something proposed in an RFC and how little that seem to bother 
anybody. That just makes serializing data much more complicated/prone to 
errors/exception.


Thanks for your work,
Dennis

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

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Hi all,

I have considered maps ... since it is possible to do in userland, I don't
consider it super urgent, and even if you do, it doesn't become urgent
until PHP 7.4 is much closer to release.

So, we have almost a year; If this flies in, it's *highly* likely I'll
follow it up ... but don't really want to spend any more time on it until I
know it's worthwhile.

Cheers
Joe


On Mon, 4 Feb 2019 at 14:30, Michael Wallner  wrote:

> On 03/02/2019 22:49, Christoph M. Becker wrote:
>
> >
> > Not sure about removal from the PHP manual.  This may never have
> > happened before (except for PECL/idn which conflicted with ext/intl).
> > Might be better to discuss this on the doc mailing list.
> >
> > F'up2 
> >
>
> Oh, it happened. I deleted http-v1 docs a few years ago.
>
> --
> Regards,
> Mike
>
>

Re: [PHP-DEV] Disable PEAR by default

[Pierre Joye]

On Tue, Feb 5, 2019, 9:09 PM Nikita Popov  On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski  wrote:
>
> I think the main question we need to decide if we might want to go a step
> further and not just disable PEAR by default, but rather remove the option
> from configure entirely. Either right away in PHP-7.4 or in master for PHP
> 8.


I would go with a warning in 7.4 and remove entirely in 8.

best,
Pierre

>

Re: [PHP-DEV] Disable PEAR by default

[Nikita Popov]

On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski  wrote:

>
>
> On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov  wrote:
>
>> Hi internals,
>>
>> I would like to suggest that installation of PEAR is disabled by default
>> in
>> PHP 7.4. PR: https://github.com/php/php-src/pull/3781
>
>
> This thread went a bit off topic, but to return to its original subject -
> I'm also supportive of this move.
>
> Zeev
>

I think the main question we need to decide if we might want to go a step
further and not just disable PEAR by default, but rather remove the option
from configure entirely. Either right away in PHP-7.4 or in master for PHP
8. It's always easy to manually install PEAR via go-pear.phar (well, apart
from right now because pear.php.net is down -- but then again the
--enable-pear option is also broken now).

Given that PHP 7.4 already comes with lots of ./configure changes due to
the migration to pkg-config, which will require people to adjust their
configure lines anyway, this might be a good moment to drop the PEAR flag
altogether.

Nikita

Re: [PHP-DEV] New website for the PHP project

[Rowan Collins]

On 5 February 2019 13:51:45 GMT+00:00, "Johannes Schlüter" 
 wrote:
>I for one don't think we need news going back to 2017 on the frontpage.
>I would like a stronger emphasis on the docs and maybe making the
>search more obvious (you have direct access to all docs from there -
>it's not just a stupid site search!)

Yes, a "most recent N news articles" with a "view older news" link would make 
sense, and give room for some other sections like prominent links to main 
documentation sections, bug tracker, etc.

This would be a good incremental improvement within the current look and feel, 
and is more likely to be completed successfully than several months of 
root-and-branch redesign.

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] phpenmod/phpdismod

[Lester Caine]

On 04/02/2019 06:24, Remi Collet wrote:

P.S. I have never understand the need of such tools...
did it made sense in previous century, where download have a cost ?

BTW, on package linux distro, when I install a webapp which depends on
some extensions, I obviously expect than everything needed is enabled...


It's nice to be able to ignore MySQL and Postgres when one is not using 
them in production, so the ability simply to load those extensions one 
actually uses is a nice to have ...


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

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

Re: [PHP-DEV] phpenmod/phpdismod

[Johannes Schlüter]

On Mo, 2019-02-04 at 07:24 +0100, Remi Collet wrote:
> 
> P.S. I have never understand the need of such tools...
> did it made sense in previous century, where download have a cost ?
> 
> BTW, on package linux distro, when I install a webapp which depends
> on
> some extensions, I obviously expect than everything needed is
> enabled...

I have no insight into Debian/Ubuntu's reasoning, but I think a factor
is that sometimes you want stuff only in some SAPI. Obviously readline
and pcntl are not good in apache sapis. (well and after those my
examples end and those could also be handled by the packaging system
...) and I thnk the logic follows their way of handling i.e. apache
modules which have to be enabled a2enmod/a2dismod.

Anyways, the feature in this way has little use in current vanilla PHP
and is more a topic for when we revamp the pecl/extension handling.

johannes


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

Re: [PHP-DEV] New website for the PHP project

[Johannes Schlüter]

On Mo, 2019-02-04 at 15:32 +0200, Andrey Andreev wrote:
> Hi,
> 
> I could nitpick on most of the proposed plan, but I really only
> wanted
> to reply to this:
> 
> > 
> > > 
> > > * A new home page, not a "news" page, but a page simply showing
> > > the PHP Logo, a code example maybe and
> > > the download link [3].
> > > 
> > > [...]
> > > 
> > > [3] https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a
> > > 91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f5844776752
> > > 61662e706e67
> I just hate those useless landing pages.
> 
> Yes, it looks neat and clean, but after the initial "OMG so pretty"
> phase it just becomes annoying - noone cares about the code example
> and I for one never know what "Get Started" means. PHP isn't some
> consumer desktop software; nobody would just stumble upon php.net and
> "get started" with it, whatever that means ...
> 
> I'm all for a modern look and all, but let's please keep the news on
> the index page. Personally, I only go to php.net to look for the
> news,
> changelogs and to search the docs. This image suggests that I'd need
> to do an extra click for each of those things and I'm sure I wouldn't
> be the only one unhappy about that.

I for one don't think we need news going back to 2017 on the frontpage.
I would like a stronger emphasis on the docs and maybe making the
search more obvious (you have direct access to all docs from there -
it's not just a stupid site search!)

johannes

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

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

[Girgias]

On Tue, 5 Feb 2019 at 14:29, Nikita Popov  wrote:

> On Tue, Feb 5, 2019 at 1:23 PM Girgias  wrote:
>
>> On Tue, 5 Feb 2019 at 12:22, Nikita Popov  wrote:
>>
>>> [. . .]
>>>
>>
>> I'm all for it but what is the scope of the RFC?
>> Is it all core functions, bundled extension functions, or all extension
>> functions?
>>
>
> It affects all internal functions using the zpp APIs, which covers pretty
> much all core functions, bundled extension functions and third-party
> extension functions.
>

Thanks for the clarification, that's great

Also does this means that there will be argument type hinting in core
>> functions that
>> could be found out via reflection?
>>
>
> Not as a direct result of the proposal, but the RFC does remove the big
> blocker for it. Once it lands we need one more change (don't actually
> verify arginfo types for internal functions to avoid double type checking),
> and then we can start adding the necessary type information. That will also
> take some work, as we have many functions, but it's something everyone can
> help with.
>
> Nikita
>

I suppose if this RFC gets voted (and implemented) there should be enough
(maybe I'm wrong) time to also implement this.

Really like this RFC even with the potential BC break as there are Static
analysis tools (such as PHPStan, Psalm and forgot the third major one)
which can help point out potential type errors.

Best regards

George P. Banyard

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

[Nikita Popov]

On Tue, Feb 5, 2019 at 1:23 PM Girgias  wrote:

> On Tue, 5 Feb 2019 at 12:22, Nikita Popov  wrote:
>
>> Hi internals,
>>
>> I'd like to bring forward the following proposal for PHP 8, which will
>> make
>> (zpp) parameter parsing failures always result in a TypeError (rather than
>> generating a warning+null, depending on circumstances):
>>
>> https://wiki.php.net/rfc/consistent_type_errors
>>
>> The goal here is to remove one of the inconsistencies between user-defined
>> and internal functions, and to put us in a position where we can actually
>> start specifying type information in arginfo without fear of breaking
>> things.
>>
>> Regards,
>> Nikita
>>
>
> I'm all for it but what is the scope of the RFC?
> Is it all core functions, bundled extension functions, or all extension
> functions?
>

It affects all internal functions using the zpp APIs, which covers pretty
much all core functions, bundled extension functions and third-party
extension functions.


> Also does this means that there will be argument type hinting in core
> functions that
> could be found out via reflection?
>

Not as a direct result of the proposal, but the RFC does remove the big
blocker for it. Once it lands we need one more change (don't actually
verify arginfo types for internal functions to avoid double type checking),
and then we can start adding the necessary type information. That will also
take some work, as we have many functions, but it's something everyone can
help with.

Nikita

Re: [PHP-DEV] [RFC] Consistent type errors for internal functions

[Girgias]

On Tue, 5 Feb 2019 at 12:22, Nikita Popov  wrote:

> Hi internals,
>
> I'd like to bring forward the following proposal for PHP 8, which will make
> (zpp) parameter parsing failures always result in a TypeError (rather than
> generating a warning+null, depending on circumstances):
>
> https://wiki.php.net/rfc/consistent_type_errors
>
> The goal here is to remove one of the inconsistencies between user-defined
> and internal functions, and to put us in a position where we can actually
> start specifying type information in arginfo without fear of breaking
> things.
>
> Regards,
> Nikita
>

I'm all for it but what is the scope of the RFC?
Is it all core functions, bundled extension functions, or all extension
functions?
Also does this means that there will be argument type hinting in core
functions that
could be found out via reflection?

Best regards

George P. Banyard

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Tue, Feb 5, 2019 at 11:45 AM Dmitry Stogov  wrote:

>
>
> On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> >
> >
> > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  > > wrote:
> >
> >
> >
> > On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> >  >
> >  >
> >  > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei
> > mailto:kont...@beberlei.de>
> >  > >> wrote:
> >  >
> >  >
> >  >
> >  > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> > mailto:dmi...@zend.com>
> >  > >> wrote:
> >  >
> >  > Hi Internals,
> >  >
> >  >
> >  > I'm glad to finally propose including JIT into PHP.
> >  >
> >  >
> >  > https://wiki.php.net/rfc/jit
> >  >
> >  >
> >  > In the current state it may be included both into PHP-8,
> > where
> >  > we are going to continue active improvement, and into
> > PHP-7.4,
> >  > as an experimental feature.
> >  >
> >  >
> >  > Can you give some information on if there are pre-conditions
> that
> >  > must hold for a function to be jitted, or quit conditions
> > that force
> >  > the JIT to be reverted for a function?
> >
> > -dopcache.jit=1245 will lead to JIT only functions with @jit
> > doc-comment
> > tag. It's possible to extend this manual control.
> >
> >
> > @jit works if I have full control over my code-base, but whenever I use
> > libraries/frameworks this kind of configuration is too static, and puts
> > a burden on open-source maintainers to figure out what they want to jit
> > or not for users.
> >
> > This option will not be very useful from a distributed maintenance
> > perspective, especially if you don't know if users pick 4 or 3, this is
> > too much configuration details/micro-management in my opinion,
> > especially given your argument that JIT is supposed to be as transparent
> > and behind the scenes as possible for users.
> >
> > In my opinion 4 should not be available to users.
>
> In some cases it may help (similar to "inline" in C).
> For better performance, I would recomend "hot counters trigger" - 3 or
> everything - 0.
>
> >
> >
> >  > In addition, it would be
> >  > helpful for testing if there was a way to find out if a
> > function was
> >  > jitted, maybe through ReflectionMethod/Function or
> >  > opcache_get_status() ?
> >
> > yes. This makes sense.
> >
> >  >
> >  > And as a follow up, the JIT seems to affect zend_execute_ex and
> >  > zend_execute_internal based profiling (tested with
> > tideways_xhprof) in a
> >  > way that all Jitted functions are not called through those two
> hooks
> >  > anymore, and don't appear in profiling data anymore. Is that a
> > correct
> >  > description? The number of parent=>child call entries drops from
> > 88 to
> >  > 12 in my sample code when jit is activated.
> >  >
> >  > Is that a desired side-effect?
> >
> > Yes. This is, at least expected.
> > PHP profilers/debuggers may disable JIT and opcache for particular
> > request, setting "opcache.enable=0" in RINIT.
> >
> >
> > This may be acceptable for development profilers, but it is not for
> > production profiling such as Blackfire and Tideways. I see that
> > overwriting internal function pointers still works for hooks, so that
> > doesn't need improvement, but PHP extensions need a way to control
> > zend_execute_ex behavior, or get an alternative hook for jit based
> > execution.
>
> JIT doesn't make a lot of sense if it doesn't optimize the overhead of
> interpretation (nested calls to execute_ex, etc). It's clear, that it's
> more difficult to debug optimized native code. Most implementations
> fallback to interpretation when need debugging. Profiling of optimized
> code is possible, but requires additional hooks.
>

I understand, but its not about preventing execute_ex for all calls, just
for the 50ish that I am interested in, high level framework functions that
are probably not efficently Jitted anyways.

For Tideways as production profiler, I am obviously interested in users
having great performance, but our users trust us to instrument what is
necessary to find out what might be wrong.


> > For Xhprof style profilers, a hook that gets the class + function name
> > alone would be enough.
> >
> > For tracing profilers based on a whitelist of a few instrumented
> > functions like tideways, NewRelic and probably all other APM vendor
> > extensions, there needs to be a hook to selectively decide "don't JIT
> > this function", that can be hooked into from 0 to many extensions.
> > Example, Tideways hooks into the userland function Mage::logException(),
> > to detect that Magento has thrown an exception that leads to a 500 page
> > being rendered. It 

[PHP-DEV] [RFC] Consistent type errors for internal functions

[Nikita Popov]

Hi internals,

I'd like to bring forward the following proposal for PHP 8, which will make
(zpp) parameter parsing failures always result in a TypeError (rather than
generating a warning+null, depending on circumstances):

https://wiki.php.net/rfc/consistent_type_errors

The goal here is to remove one of the inconsistencies between user-defined
and internal functions, and to put us in a position where we can actually
start specifying type information in arginfo without fear of breaking
things.

Regards,
Nikita

Re: [PHP-DEV] Simplify license headers

[Peter Kokot]

On Mon, 4 Feb 2019, 02:32 Peter Kokot  On Wed, 30 Jan 2019 at 13:57, Derick Rethans  wrote:
> >
> > On Mon, 28 Jan 2019, Zeev Suraski wrote:
> >
> > >
> > > > I would like to make two changes to this header:
> > > >
> > > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity
> of updating this for
> > > > new major versions. I don't think the version information here is
> particularly useful to
> > > > anybody.
> > >
> > > I don't mind that much, but I don't see any issue with keeping it the
> way it is either.  It does look nicer the way it is now IMHO, and the cost
> associated with changing it twice a decade is, well, not very substantial.
> > >
> > > > 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart
> from requiring a
> > > > yearly update, this line is actually complete misinformation,
> because the PHP group
> > > > does *not* hold the copyright for the PHP source code. This would
> require a copyright
> > > > assignment agreement on behalf of all contributors, which we do not
> collect.
> > > >
> > > > We could also just drop the header entirely, I'm just proposing
> these two changes as
> > > > the path of least resistance towards getting the "annoying" parts
> removed.
> > >
> > > I'm no lawyer, but I do believe a case can be made for claiming that a
> > > person putting code into files with the header 'Copyright (c) XYZ', is
> > > in fact implicitly assigning copyright to XYZ.  So while it's not as
> > > strong as an explicit copyright assignment, and while it was never
> > > tested in court (and hopefully never will be) - I do see value in
> > > keeping it.  I certainly don't see a reason to change it after 20
> > > years where it didn't seem to bother anybody, unless there's a strong
> > > reason to do that, which currently I don't see.
> >
> > It could be changed to "1997-present" though, in which case it doesn't
> > need updating once a year (and messing up history in VCS).
> >
> > cheers,
> > Derick
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> Hello,
>
> I've prepared quick pull request [1] that fixes the missed headers in
> source code files and additionally bumps or changes the year range on
> other places.
>
> Questions:
>
> 1.) What should "php -v" output regarding copyrights and year ranges?
> 2.) What should "man php" include under the COPYRIGHT section
> regarding the year ranges?
> 3.) Similarly, should there be a common pattern for places like
> phpinfo() output?
>
> Thanks.
>
> [1] https://github.com/php/php-src/pull/3791
>
> --
> Peter Kokot
>

The pull request with a quickfix [1] to sync the year ranges will be merged
this weekend if everyone's ok with this... So now, only the LICENSE file
optionally gets bumped the year ranges and that simplifies managing files
significantly for the better. Thank you.

[1] https://github.com/php/php-src/pull/3791

>

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

[Zeev Suraski]

On Tue, Feb 5, 2019 at 12:09 PM Andrey Andreev  wrote:

> Hi again,
>
> On Tue, Feb 5, 2019 at 10:37 AM Zeev Suraski  wrote:
> >
> > Regardless of what you did, actually obtaining full voting rights
> > meant you had to ask for a VCS account, and have a reasonably good
> > explanation on why you need one - enough to convince one of the folks
> > with admin rights on master.php.net to click the 'Accept' button.
>
> This is what I don't understand.
>
> On one hand you say one needs to make a convincing enough request, so
> that it may be granted by admins such as yourself. To me, that sounds
> reasonable-ish (with some reserves, but certainly different to yours)
> as I can't imagine that commit access to a project like PHP is handed
> out left and right to anybody who wants it. But in the same breath you
> also say that's a low bar.
>

I see no contradiction between the two.  The approval process for a VCS
account should absolutely not be coupled with the ability to vote.  They
were never intended to be one and the same and they're not supposed to be
based on the currently-approved Voting RFC.  Voting rights actually don't
play a major role in the decision on whether to grant someone a VCS account
- it's predominantly whether the one requesting it would need access to
just one of the PHP repositories (it can also be the php.net website, for
that matter).

Also, to me it does not sound reasonable or even reasonable-ish at all that
any one person - whether they're admin on master.php.net or not - would be
able to grant others with voting rights.


> If that's a low bar (to which I don't agree, but I also don't make
> these decisions so idk), then perhaps the vetting process itself
> should be revised. How can you trust your peers to grant commit
> access, but not a say in how things should go forward? That's a
> contradiction to me.
>

It don't view it as a contradiction.  VCS access is really an
administrative matter of convenience.  You can grant someone access to the
VCS (which again, isn't just for php-src but for many other repositories as
well) - but in terms of what they're allowed to do with this access,
they're still subject to the rules of what they may and may not do.  VCS
access in itself doesn't give anybody any special power, as all changes are
out in the open and virtually all of them are peer reviewed.  If they do
something which they're not supposed to do - it will be reverted.  Coupling
this administrative step with immediate implicit voting rights is not a
matter of convenience, it's a matter of substance.  And it is, indeed, a
way-too-low (and arguably completely nonsensical) bar to clear.

> That's all.  Immediately, one has identical rights to someone who may
> > have been spending years of their time on PHP, in a one way ticket.
> >
>
> There will always be new kids in the block and you have to accept that
> if you want to attract any contributors at all.


Having new kids in the block is crucial, but it does not immediately call
for having an extremely low bar for full voting rights.  We shouldn't
underestimate the attractiveness of having full voting rights on one of
biggest development platforms in the world.  It also goes both ways, if
it's entirely too easy to get voting rights, the value in having them
diminishes.  At the same time - setting a higher bar than the
virtually-non-existent one we have right now may motivate contributors to
contribute a bit more if they want to have a say in the direction the
project takes as a whole.

Zeev

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> 
> 
> On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
>  >
>  >
>  > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei
> mailto:kont...@beberlei.de>
>  > >> wrote:
>  >
>  >
>  >
>  >     On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> mailto:dmi...@zend.com>
>  >     >> wrote:
>  >
>  >         Hi Internals,
>  >
>  >
>  >         I'm glad to finally propose including JIT into PHP.
>  >
>  >
>  > https://wiki.php.net/rfc/jit
>  >
>  >
>  >         In the current state it may be included both into PHP-8,
> where
>  >         we are going to continue active improvement, and into
> PHP-7.4,
>  >         as an experimental feature.
>  >
>  >
>  >     Can you give some information on if there are pre-conditions that
>  >     must hold for a function to be jitted, or quit conditions
> that force
>  >     the JIT to be reverted for a function?
> 
> -dopcache.jit=1245 will lead to JIT only functions with @jit
> doc-comment
> tag. It's possible to extend this manual control.
> 
> 
> @jit works if I have full control over my code-base, but whenever I use 
> libraries/frameworks this kind of configuration is too static, and puts 
> a burden on open-source maintainers to figure out what they want to jit 
> or not for users.
> 
> This option will not be very useful from a distributed maintenance 
> perspective, especially if you don't know if users pick 4 or 3, this is 
> too much configuration details/micro-management in my opinion, 
> especially given your argument that JIT is supposed to be as transparent 
> and behind the scenes as possible for users.
> 
> In my opinion 4 should not be available to users.

In some cases it may help (similar to "inline" in C).
For better performance, I would recomend "hot counters trigger" - 3 or 
everything - 0.

> 
> 
>  >     In addition, it would be
>  >     helpful for testing if there was a way to find out if a
> function was
>  >     jitted, maybe through ReflectionMethod/Function or
>  >     opcache_get_status() ?
> 
> yes. This makes sense.
> 
>  >
>  > And as a follow up, the JIT seems to affect zend_execute_ex and
>  > zend_execute_internal based profiling (tested with
> tideways_xhprof) in a
>  > way that all Jitted functions are not called through those two hooks
>  > anymore, and don't appear in profiling data anymore. Is that a
> correct
>  > description? The number of parent=>child call entries drops from
> 88 to
>  > 12 in my sample code when jit is activated.
>  >
>  > Is that a desired side-effect?
> 
> Yes. This is, at least expected.
> PHP profilers/debuggers may disable JIT and opcache for particular
> request, setting "opcache.enable=0" in RINIT.
> 
> 
> This may be acceptable for development profilers, but it is not for 
> production profiling such as Blackfire and Tideways. I see that 
> overwriting internal function pointers still works for hooks, so that 
> doesn't need improvement, but PHP extensions need a way to control 
> zend_execute_ex behavior, or get an alternative hook for jit based 
> execution.

JIT doesn't make a lot of sense if it doesn't optimize the overhead of 
interpretation (nested calls to execute_ex, etc). It's clear, that it's 
more difficult to debug optimized native code. Most implementations 
fallback to interpretation when need debugging. Profiling of optimized 
code is possible, but requires additional hooks.

> For Xhprof style profilers, a hook that gets the class + function name 
> alone would be enough.
> 
> For tracing profilers based on a whitelist of a few instrumented 
> functions like tideways, NewRelic and probably all other APM vendor 
> extensions, there needs to be a hook to selectively decide "don't JIT 
> this function", that can be hooked into from 0 to many extensions.
> Example, Tideways hooks into the userland function Mage::logException(), 
> to detect that Magento has thrown an exception that leads to a 500 page 
> being rendered. It should be possible to make sure this function never 
> gets jitted, so that I see its execution in zend_execute_ex.

It's easily possible to disable JIT-ing by implementing @nojit (it's 
pity, we didn't get attributes).

Thanks. Dmitry.

> 
> 
> In addition, JIT-ed functions now may be tracked by Linux perf
> (oprofile
> and Intel VTune).
> 
> $ perf record php -d opcache.huge_code_pages=0 -d
> opcache.jit_debug=0x10
> bench.php
> $ perf report
> 
> 
> I think you overestimate PHP users savyness in Linux level profiling, 
> maybe 1 in 100 knows how to use perf. In addition many PHP users don't 

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

[Stanislav Malyshev]

Hi!

> To me that is the purpose of voting, what you’re saying is like
> complaining that in a democracy old people with experience has the
> same voting power than young ones.

To be clear, PHP user community is not a democracy, neither we want to
be. In democracy, every person (marginal cases like resident aliens,
infants and prison inmates excluded) gets a vote, on the principle that
since the law apply to everyone, everyone must have a say in its design,
and once the majority decision is taken, it is mandatory to all members.

In software projects, I do not think there's been ever any project that
is a democracy of its users. While decisions of the project developers
do influence, undoubtedly, the users, it is universally true that the
users have no direct control over these decisions. Doing it the way
democracy is done would make the project ungovernable, and would likely
discourage most volunteers from working on it. Do you imagine Linus
asking a vote of all Linux users about how to implement a kernel driver
and implementing it only in a way that majority of Linux users approves?

> I’m also not sure why one would need to be coding PHP itself to be
> able to vote its direction,

Because whoever makes the thing defines how the thing is made (of
course, it takes more to make PHP than pure C coding, so I am bundling
all contributors to the project - however widely defined - together). If
you are to build a house, I am not going to tell you how to do it. It's
your house, you build it however you want it - even if you might later
invite me to visit. If I think the house is badly built, I may refuse to
come, and criticize you, but I won't claim the power to tell you how to
do it.

> I feel it’s sane that people using it have a say in it.

Have a say, as in providing feedback and advice - sure, and they do.
Having decisive voice, overriding the voice of people who actually
implement it, in their own free time, and then give it away for free - no.

> I know you (or someone else) explained having a say in it does not
> necessarily means having voting power, but I feel it does. I’m not

Unfortunately, this is wrong.

> sure without voting power I would follow closely RFCs as I do now. So
> I think this is where my main disagreement with these criteria is: I
> like that people interested in PHP can get access to voting where it
> goes.

Being just "interested" is not enough to gain decisive power over what
other people are doing. If I'm interested in US politics, that doesn't
make me a Congressman.

> You make it like it’s a gift for people to be able to vote on PHP
> RFCs while I feel like it’s good for PHP to have people voting its
> RFCs.

There's no abstract "PHP" that it'd be good for beyond people who
actually develop it. And I don't see how it'd be good for people who
develop it to give control over how to develop it to people that don't.

> This is exactly the problem with such criteria: It will push people
> to do things just to get the criteria, like fix typos in comments or
> split features in several commits to make the count. Voting system
> criteria should not influence the way we write the code.

If we get past contributors contributing again - even if by fixing typos
- I see nothing wrong with that. Maybe they'll get a taste for it and
then start fixing bugs and implementing extensions :)
In any case, I personally am for inclusion-biased system - but still not
"anything goes" system.

> One last point: Having non-core developers voting puts a higher bar
> on RFC redacting quality: The author needs to explain his feature
> well enough so that people without deep internal knowledge get it.

I don't see how the voting process prevents people that didn't get it
from voting (either way). In a democracy, people do it all the time ;)
So this is really not a solid argument for your point.

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

[Andrey Andreev]

Hi again,

On Tue, Feb 5, 2019 at 10:37 AM Zeev Suraski  wrote:
>
> Regardless of what you did, actually obtaining full voting rights
> meant you had to ask for a VCS account, and have a reasonably good
> explanation on why you need one - enough to convince one of the folks
> with admin rights on master.php.net to click the 'Accept' button.

This is what I don't understand.

On one hand you say one needs to make a convincing enough request, so
that it may be granted by admins such as yourself. To me, that sounds
reasonable-ish (with some reserves, but certainly different to yours)
as I can't imagine that commit access to a project like PHP is handed
out left and right to anybody who wants it. But in the same breath you
also say that's a low bar.

If that's a low bar (to which I don't agree, but I also don't make
these decisions so idk), then perhaps the vetting process itself
should be revised. How can you trust your peers to grant commit
access, but not a say in how things should go forward? That's a
contradiction to me.

> That's all.  Immediately, one has identical rights to someone who may
> have been spending years of their time on PHP, in a one way ticket.
>

There will always be new kids in the block and you have to accept that
if you want to attract any contributors at all.

Cheers,
Andrey.

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

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Michał Brzuchalski]

wt., 5 lut 2019 o 10:24 Côme Chilliet  napisał(a):

> Hello,
>
> What is the usecase for this?
>
> The RFC does not explain what it would be useful for.
> json_decode already provides an option for getting arrays instead of
> objects.
>
> All in all the RFC does not provide enough information. As I understand it
> if stdClass is Traversable then all objects are, no?
>
>
stdClass is not a super class so none of the objects in core neither
userland are derived from stdClass


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

-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] phpenmod/phpdismod

[Legale.legale]

On Feb 4, 2019 07:24, Remi Collet  wrote:
>
> Hi, 
>
> Le 02/02/2019 à 20:24, Legale Legage a écrit : 
> > These scripts are included to the standard deb/rpm packages 
>
> No, this is a deb only stuff 
>
> RPM installed = extension enabled. 
>
My misstake.

>
> Remi 
>
>
> P.S. I have never understand the need of such tools... 
> did it made sense in previous century, where download have a cost ? 
>
> BTW, on package linux distro, when I install a webapp which depends on 
> some extensions, I obviously expect than everything needed is enabled... 
>

Do you unmount the chandelier when you need to turn off the light? 

I expect the same when i do 'make install' for the extension, but it doesn't 
happens.

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

[Zeev Suraski]

On Tue, Feb 5, 2019 at 11:07 AM Côme Chilliet  wrote:

> Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit :
> > Regardless of what you did, actually obtaining full voting rights
> > meant you had to ask for a VCS account, and have a reasonably good
> > explanation on why you need one - enough to convince one of the folks
> > with admin rights on master.php.net to click the 'Accept' button.
> > That's all.  Immediately, one has identical rights to someone who may
> > have been spending years of their time on PHP, in a one way ticket.
>
> To me that is the purpose of voting, what you’re saying is like
> complaining that in a democracy old people with experience has the same
> voting power than young ones.
> I feel for votes to make sense you need a lot of people voting, a vote
> between the 10 core developers does not make a lot of sense, and could well
> be replaced by a discussion on a mailing list.
>
> I’m also not sure why one would need to be coding PHP itself to be able to
> vote its direction, I feel it’s sane that people using it have a say in it.
>

We'll have to agree to disagree on this one.  I would say that the way
virtually every other major Open Source project serves as a fairly good
proof point for my position.  In fact, even with the new eligible voting
criteria, we'd be well ahead of most other major OS projects in terms of
the number of people included in the process with full equal voting rights.

Zeev

Re: [PHP-DEV] New website for the PHP project

[Michał Brzuchalski]

wt., 5 lut 2019 o 04:32 azjezz  napisał(a):

> ...
> mock ups : https://github.com/azjezz/web-php-mock-ups
> screenshot :
> https://github.com/azjezz/web-php-mock-ups/blob/master/screenshots/getting-started.png
>

Is this your desired look you wanna propose? I may misunderstand and
probably am.
I made a small pinboard [1] with a collection of known programming
languages websites and
thought it might be useful. When I look at some a home page usually exposes:
* short description
* example code (with an option to run)
* get started
* latest versions
* features
* why this lang and what especially for
* some latest news (not few pages as it is right now)
* etc.

When I look at your proposed landing screenshot it doesn't differ much than
what we have now, right?
You've changed the original purple colour, why?

[1] https://pl.pinterest.com/brzuchal/programming-languages/year-2019/
-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

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

[Zeev Suraski]

On Mon, Feb 4, 2019 at 10:56 AM Stanislav Malyshev 
wrote:

> Hi!
>
> Reading the RFC, here's my thoughts:
>

Thanks for the detailed response!


> 1. Do we really need different classification of changes? I think having
> one single vote procedure would have larger benefit, and RFC that fails
> 2/3 requirement would be suspect anyway. RFCs can have parts - "whether
> we do it" and "how exactly we do it" - the former would be 2/3
> requirement, the latter can be simple plurality even - e.g. if we decide
> to have an extension for libfoobar, that should have 2/3 vote, but then
> decision between whether to name it foobar or barfoo can be decided by
> majority or plurality.
>

I think we do.  There are decisions where a 2/3 majority requirement makes
no sense, as the vote itself is about a choice between two options that are
on the table, as opposed to deciding whether to do something or not.
There aren't many such cases, but when they do occur - they tend to be
important.

The most obvious case I have in mind is that of the choice between PHP 6
and 7.  It doesn't expose us to any future commitments, doesn't change the
language - it's arguably almost a marketing decision.  Similarly, if we
decide to change our release schedule, I don't see why that should require
a 2/3 majority.  The 'bias for the status quo', which is the main reason we
have the super majority requirement to begin with, doesn't really play a
role here - as it bears no long term commitment.

2. The RFC deals simultaneously with two questions - whether vote is
> needed for certain changes and how the voting process is performed. I am
> not sure these issues should be handled together - they are
> substantially different.
>

Yes, that's something I intend to look into.


> 3. Requiring patch for each RFC is kinda high bar - if I propose some
> functionality, I don't really want to spend months on implementing it
> only to see it voted down and my time completely wasted.
>

This new workflow does not require an RFC for each patch.  It does require
an RFC for functionality that affects end users.
You do have a point regarding a scenario where you invest time into a patch
that then it ends up being rejected.  However, I think there are several
things to consider here:

- De-facto, most large RFCs actually come with an accompanied
implementation even today.
- In certain cases, the feasibility of implementation - and the ability to
do it in a reasonable, high performance way - are substantial parts of the
decision on whether to accept the RFC or not.
- Usually, it's possible to gauge the level of interest/acceptance even
before beginning work on the patch and/or working on the RFC.  This
workflow does not intend to replace all of the discussions on internals or
other avenues, and it may make sense to explicitly suggest in the workflow
to informally discuss the proposal with fellow contributors before
investing heavily in the implementation or RFC.
- Perhaps most importantly, I think it's very difficult to create a simple,
repeatable criteria to determine which end-user-affecting change requires
an RFC and which one doesn't.  Still, perhaps we can employ something like
Larry's approach - i.e., some sort of a "pre-RFC" stage where the author
asks for an 'exemption' from the full process for a small patch, and they'd
get it as long as there are no eligible voters opposing (say, 3 of them, or
whatnot).

>
> 4. I am feeling a bit uneasy about any change requiring a week's waiting
> period - read literally, that means you'd better not fix typos in your
> RFC if you don't want for it to take forever, and certainly not address
> feedback like "X is not documented enough" or "Y description could be
> clearer". I do think substantial changes require discussion and in some
> cases even full re-launch of the RFC but requiring a week's wait for any
> change, even the trivial one, seems going to far to me.
>

Again, here too drawing the line is difficult.  Typos are easy (although
certain types of typos can be quite strategic), but sometimes things like
further documentation may result in different levels of support for the
RFC.  That's why I like Larry's approach and would try to build it into the
workflow - small changes will be permitted to the RFC without resetting the
clock, but that's provided there's consensus that they're indeed small
(e.g.., fewer than 3 eligible voters object).

5. The RFC changes [VOTE] subject that we've used before to [RFC VOTE].
> I know it's a nitpick but is that change necessary? If people had
> filters to match such things, the change would break them and I'm not
> sure it improves anything.
>

Agreed, fixed.


> 6. I think we should allow longer voting periods than 1 week. In fact,
> I'd go as far as recommend longer minimum even, but even if we keep
> minimum of 1 week, there would be cases - holidays, conferences, sports
> events ;) - where a lot of people could be offline for prolonged time
> and 1 week won't be nearly 

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  wrote:

>
>
> On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei  > > 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.
> >
> >
> > Can you give some information on if there are pre-conditions that
> > must hold for a function to be jitted, or quit conditions that force
> > the JIT to be reverted for a function?
>
> -dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
> tag. It's possible to extend this manual control.
>

@jit works if I have full control over my code-base, but whenever I use
libraries/frameworks this kind of configuration is too static, and puts a
burden on open-source maintainers to figure out what they want to jit or
not for users.

This option will not be very useful from a distributed maintenance
perspective, especially if you don't know if users pick 4 or 3, this is too
much configuration details/micro-management in my opinion, especially given
your argument that JIT is supposed to be as transparent and behind the
scenes as possible for users.

In my opinion 4 should not be available to users.


> > In addition, it would be
> > helpful for testing if there was a way to find out if a function was
> > jitted, maybe through ReflectionMethod/Function or
> > opcache_get_status() ?
>
> yes. This makes sense.
>
> >
> > And as a follow up, the JIT seems to affect zend_execute_ex and
> > zend_execute_internal based profiling (tested with tideways_xhprof) in a
> > way that all Jitted functions are not called through those two hooks
> > anymore, and don't appear in profiling data anymore. Is that a correct
> > description? The number of parent=>child call entries drops from 88 to
> > 12 in my sample code when jit is activated.
> >
> > Is that a desired side-effect?
>
> Yes. This is, at least expected.
> PHP profilers/debuggers may disable JIT and opcache for particular
> request, setting "opcache.enable=0" in RINIT.
>

This may be acceptable for development profilers, but it is not for
production profiling such as Blackfire and Tideways. I see that overwriting
internal function pointers still works for hooks, so that doesn't need
improvement, but PHP extensions need a way to control zend_execute_ex
behavior, or get an alternative hook for jit based execution.

For Xhprof style profilers, a hook that gets the class + function name
alone would be enough.

For tracing profilers based on a whitelist of a few instrumented functions
like tideways, NewRelic and probably all other APM vendor extensions, there
needs to be a hook to selectively decide "don't JIT this function", that
can be hooked into from 0 to many extensions.

Example, Tideways hooks into the userland function Mage::logException(), to
detect that Magento has thrown an exception that leads to a 500 page being
rendered. It should be possible to make sure this function never gets
jitted, so that I see its execution in zend_execute_ex.


> In addition, JIT-ed functions now may be tracked by Linux perf (oprofile
> and Intel VTune).
>
> $ perf record php -d opcache.huge_code_pages=0 -d opcache.jit_debug=0x10
> bench.php
> $ perf report
>

I think you overestimate PHP users savyness in Linux level profiling, maybe
1 in 100 knows how to use perf. In addition many PHP users don't have root
on their servers (managed). And within Docker you don't even get there to
start perfing. Profilers that put user experience first must be PHP
extensions, so we need to make sure the basic level of hooking is possible
even though we have a JIT.


>
> Thanks. Dmitry.
>
>
>
> >
> >
> >
> > Thanks. Dmitry.
> >
>

Re: [PHP-DEV] [VOTE] Making stdClass iterable

[Côme Chilliet]

Hello,

What is the usecase for this?

The RFC does not explain what it would be useful for.
json_decode already provides an option for getting arrays instead of objects.

All in all the RFC does not provide enough information. As I understand it if 
stdClass is Traversable then all objects are, no?

Côme

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

[Legale.legale]

This is truly developer way. :-)

On Feb 5, 2019 01:10, "Christoph M. Becker"  wrote:
>
> On 04.02.2019 at 23:59, Kalle Sommer Nielsen wrote: 
>
> > Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield 
> > : 
> > 
> >> To answer both you and Sanislav here together, as he raised a similar 
> >> point, 
> >> that presumes that 100% of the "invited outsiders" vote on every RFC.  I 
> >> think 
> >> that is unlikely, although I freely admit I have no real data to speculate 
> >> either way.  Lacking any other evidence I'd say it would probably follow a 
> >> similar pattern to Internals day.  (If we assume a 175 person voting pool 
> >> and 
> >> a turnout of about 50, then that's in the neighborhood of 25-30%.) 
> >> Truthfully, though, none of us have any idea what the total impact would 
> >> be. 
> > 
> > As a continuation of my answer above to this one; By looking at the 
> > average turnout of people voting as it is now, there is a 50%+ of 
> > people with just doc karma in one way or another (single translation), 
> > just PEAR or even some without any form of karma voting. Looking at 
> > the list of the 175 or so posted, it is a very small margin of those 
> > on average that votes for RFCs, meaning that adding externals to the 
> > top of that, that number in my original email is gonna be a lot larger 
> > and therefore a lot more dangerous if we open the floodgates like 
> > that. 
>
> In my opinion, the question “who is eligible to vote” is closely tied to 
> the RFC *at hand*.  For instance, str_begins() wouldn't be much of a 
> maintainance burden, and whether it should be included into the PHP core 
> could very well also be decided by some of those who won't contribute to 
> the implementation/maintainance.  On the other hand, whether to add JIT 
> compilation may better only be decided by those who would have to 
> maintain the implementation and who can assess related issues and 
> pitfalls (I'm none of those), but not by those who only can fancy “hey, 
> JIT is cool – let's have it!”  It's obviously hard to lay down 
> respective rules, though. 
>
> Anyhow, instead of suggesting some “general improvements/refinements” to 
> the RFC process, in my opinion, we should identify *where* exactly our 
> RFC process has failed, and *why* it did so.  Then we should eliminate 
> the bugs (if there are any). 
>
> -- 
> Christoph M. Becker 
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php 
>

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

[Côme Chilliet]

Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit :
> Regardless of what you did, actually obtaining full voting rights
> meant you had to ask for a VCS account, and have a reasonably good
> explanation on why you need one - enough to convince one of the folks
> with admin rights on master.php.net to click the 'Accept' button.
> That's all.  Immediately, one has identical rights to someone who may
> have been spending years of their time on PHP, in a one way ticket.

To me that is the purpose of voting, what you’re saying is like complaining 
that in a democracy old people with experience has the same voting power than 
young ones.
I feel for votes to make sense you need a lot of people voting, a vote between 
the 10 core developers does not make a lot of sense, and could well be replaced 
by a discussion on a mailing list.

I’m also not sure why one would need to be coding PHP itself to be able to vote 
its direction, I feel it’s sane that people using it have a say in it. 
I know you (or someone else) explained having a say in it does not necessarily 
means having voting power, but I feel it does.
I’m not sure without voting power I would follow closely RFCs as I do now.
So I think this is where my main disagreement with these criteria is: I like 
that people interested in PHP can get access to voting where it goes.

> As I mentioned above, the criteria is open for debate.  From my POV
> though, having such a criteria and implementing it - even if it's 7.5
> years too late - is a must.
> I agree that a commit count isn't a good criteria on its own, but as
> mentioned above - I think it adds value as an added bar for the
> already-low 500 line count.
> I consider both criteria as fairly low bars for full voting powers on
> one of the most popular open source projects in the world.

You make it like it’s a gift for people to be able to vote on PHP RFCs while I 
feel like it’s good for PHP to have people voting its RFCs.

> Also note that the 'Grandfathering' period aims at providing a
> reasonable transition for those who are borderline qualified to vote,
> and gives them a full year to clear the bar to retain their full
> voting rights.

This is exactly the problem with such criteria: It will push people to do 
things just to get the criteria, like fix typos in comments or split features 
in several commits to make the count.
Voting system criteria should not influence the way we write the code.

One last point: Having non-core developers voting puts a higher bar on RFC 
redacting quality: The author needs to explain his feature well enough so that 
people without deep internal knowledge get it. This is a good thing.

Côme

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

[Zeev Suraski]

> -Original Message-
> From: Andrey Andreev 
> Sent: Tuesday, February 5, 2019 5:18 AM
> To: Zeev Suraski 
> Cc: Dan Ackroyd ; PHP internals
> 
> Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
>
> You keep saying that, but it hasn't been explained how it is so.

It's simple.  It's very easy to get a VCS account.  You basically just ask,
and if the request is reasonable - you'll get one.  It's enough for one of
the folks who have admin rights on master.php.net to think that the request
is reasonable for them to grant it to you.  That's it.
You may consider that a reasonable bar, I don't.  Nor was this ever a
bar agreed upon by the developers.

> Is it the PEAR-only contributors that you want to eliminate? The doc &
> translations teams? Old-timers who are no longer interested in the
> project? Is
> there a common occurrence of existing leaders granting VCS accounts to
> friends
> for no reason?
> I mean, if you want to reduce thousands to sub-200, you might as well put
> down
> all your cards.

My cards are simple - the current de-facto bar is not sensible.  It was
never intended.  It is not backed by anything the code contributors ever
agreed to.  It has no parallels in other OS projects.  It stems from one
source and one source alone - it was the easiest way to get the voting
process up and running in a fully automated way.  It would effect many
sub-groups, but the idea isn't about who to exclude, but rather - who to
include.  It includes those who have contributed to the PHP project itself,
have made a sizeable contribution and over a period of time.  Exactly like
it is in mostly every other open major source project (at least one that has
no BDFL(s)).

> Aside from a couple of past cases where "ghost" voters were mobilized for
> a
> huge, controversial RFCs, I haven't seen a problem with the current voting
> pool
> members (and thus see little reason to attempt to change it), but I also
> think it's
> sensible that e.g. translating a couple of lines in the docs isn't enough.
> In any
> case however, the criteria and metrics that you've chosen are, to me,
> quite
> arbitrary and only appear fair while not actually being so, especially the
> 25
> commit count.

We can (and should) debate the criteria.  The rationale was to have bars on
both the contribution's size, as well as its breadth.  The number of commits
tended to correlate with contributions over time, as opposed to one-time
contributions.  There may be better ways of determining that, I'm open to
suggestions.

> Full disclosure - that last one is what disqualifies me. Although, I
> certainly don't
> consider myself a "core" developer, so if your intention is to limit
> voting power
> to only that group I guess it has achieved the goal in my case.

Well, honestly, I don't think the 25 commit / 500 line bar qualifies anybody
as a core developer, and that's not what I'm trying to establish.  It was
actually purposely what I at least consider a very low bar - that allows
newcomers to become voters relatively quickly (within several months to a
year), by showing a certain level of interest and commitment.

True core developers clear bars that are two orders of magnitude
larger, as you can see for yourself in the Git statistics.

> On the other hand, I qualify under all the current status-quo criteria
> - I've contributed some code, features, tests, docs; had a couple of RFCs;
> am a
> lead framework developer; participate somewhat regularly in internals
> discussions - yet obtaining voting privilege wasn't as easy as a
> "ridiculously low
> bar" would make you believe.

Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.
That's all.  Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.

Setting certain bars on the ability to influence the direction the
language is going does not in any way take away from the work you or
others did.  PHP benefits greatly from contributions of hundreds of
thousands of people in various fronts.  The vast majority of those
don't have voting powers today, including ones that have similar (or
different but equivalent) credentials to the ones you mentioned, but
didn't apply for a VCS account.  Whether or not we should provide
non-code-contributors with voting rights is a tough question (as can
be seen on other posts on this thread), but I do think that the 'base
group' of those who should have voting powers should be the code
contributors - and we therefore need some definitions on what
qualifies one as a code contributor.  Including other criteria (such
as tests, docs, framework contribution, etc.) is probably not
feasible, as it would be very difficult to apply in an even manner
(and no, what we have right now 

Re: [PHP-DEV] New website for the PHP project

[Côme Chilliet]

Le lundi 4 février 2019, 14:44:31 CET Rowan Collins a écrit :
> In general, though, I quite like the current site design, and would much
> rather effort was spent iteratively improving it, rather than throwing it
> away and implementing a new set of bugs.
> 
> My personal annoyance is the search result page; specifically, that the
> "Full website search" link appears in the sidebar like it's an
> afterthought, rather than prominently with the search results, or as a
> separate results tab or something.

I agree, I like the current website and design and would see much more value in 
an attempt at fixing small problems one by one rather than trying to redo the 
whole thing at once.

Change the pages organization a bit would improve things, but the design do not 
need to change.

For example I hate how this page https://php.net/support has the "Table of 
Contents" on the right while this one https://php.net/get-involved.php has 
unique information in the same place that you overlook the first time you read 
the page.
When I tried to get involved in PHP the first time, I got to 
https://php.net/get-involved.php, read the "Development of the PHP source" 
section and was like «Hum, ok, but where is the source? Why aren’t there any 
links here?». The stuff in the right column should really be in the middle and 
replaced with a Table of contents for consistency IMO.

Côme

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