date:20190204



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.

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

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

Thanks. Dmitry.



> 
> 
> 
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] JIT



On 2/4/19 11:39 PM, Bruce Weirdan wrote:
> After figuring out that opcache.jit_buffer_size is specified in bytes
> (not in megabytes, as RFC states)

Thanks for catching this. Fixed.

> I got ~5% speedup running
> vimeo/psalm (static analyzer) on its own codebase with default
> JIT flags and ~7.3% with minimal JIT (1201).
> 
> 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.

Thanks. Dmitry.

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

Hi again,

On Tue, Feb 5, 2019 at 5:32 AM Kris Craig  wrote:
> Stripping any existing contributors of our voting rights is a non-starter for 
> me, period.  Any changes must not be applied retroactively, as that would 
> just lead to all kinds of problems and severe animosity/drama.
>
> The eligibility needs to be moved to its own RFC and fixed so that it doesn't 
> overreach by trying to force out existing voters.  Otherwise you can count me 
> as a firm "no" on this one.
>

Indeed, both excellent points and you can count me in favor of
splitting eligibiity into a separate RFC.

Cheers,
Andrey.

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

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

2019-02-04 Thread Kris Craig

On Mon, Feb 4, 2019, 7:18 PM Andrey Andreev  Hi,
>
> I was avoiding this, but since the discussion has already turned into
> all about who gets to vote, I might as well ...
>
> On Tue, Feb 5, 2019 at 1:46 AM Zeev Suraski  wrote:
> > the barrier to obtaining a vote is ridiculously low.
>
> You keep saying that, but it hasn't been explained how it is so.
>
> 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.
>
> 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.
>
> 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.
> 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.
>
> Anyone who has ever attempted to use such metrics for evaluation would
> tell you that commit count is a horrible one. It makes no difference
> between 25 and 25k lines, quality or significance.
> It doesn't give any weight to participation in discussions either,
> whether its on this list or code reviews, both of which I believe are
> influential and valuable.
> Some squash commits, some don't; I've had my own commits squashed AND
> authored by the person who merged them, meaning my name isn't attached
> to them at all. This is an example of a previously meaningless factor
> all of a sudden becoming a deciding one.
> There are some well-known names that don't make the cut in Appendix A
> and that does raise an eyebrow.
>
> If you want to say that there are people with voting privileges that
> haven't earned them, that's one thing, but (and I'm not assuming bad
> intentions with this) as it stands it looks like you just wanted to
> cut as much as possible and only looked for a metric that wasn't going
> to eliminate the very top contributors, whom you can't afford to lose.
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Stripping any existing contributors of our voting rights is a non-starter
for me, period.  Any changes must not be applied retroactively, as that
would just lead to all kinds of problems and severe animosity/drama.

The eligibility needs to be moved to its own RFC and fixed so that it
doesn't overreach by trying to force out existing voters.  Otherwise you
can count me as a firm "no" on this one.

>
>

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

On Tuesday, February 5, 2019 2:20 AM, Andrey Andreev  wrote:

> Hi,
>
> On Mon, Feb 4, 2019 at 5:14 PM azjezz azj...@protonmail.com wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, February 4, 2019 2:32 PM, Andrey Andreev n...@devilix.net 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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> > >
> > > 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.
> > > Cheers,
> > > Andrey.
> >
> > The landing page is meant for the new comers to PHP, when people search for 
> > php, the home page is the first to appear. it make sense to show a sample 
> > and a straightforward button to get started with using PHP ( introduction, 
> > installation and tutorial )
>
> There's a missing link here - who searches for "php" without prior
> knowledge of what it is? Programming languages aren't buzzwords that
> come up in casual conversations between people who don't already use
> them.
>
> And how does it make sense to show a code sample? What for? The only
> time I've seen isolated, meaningless code samples serve a purpose is
> to look cool in movies.
>
> Now that you mentioned a tutorial, that's one thing I agree is useful
> and missing. As a self-learner myself, 15 years ago I would've
> appreciated a vetted selection of tutorials on the official website.
> But why not just put a "Tutorials" link alongside "Documentation"?
>
> > You can see the mock up repository for what the "Getting Started" page 
> > would look like.
>
> No such thing had been linked until your last reply (which was sent
> after I started writing this), but that's my point exactly - you have
> to look at it first in order to know what's hiding behind it and
> that's counter-productive to me; I reiterate the suggestion to have a
> "Tutorials" link instead.
>
> > if you usually visit the website for documentation, you would just type 
> > php.net/documentation in the url bar instead of php.net or php.net/blog for 
> > changelogs and articles.
>
> See, this is where you actually make the site harder to use.
>
> Today, I only type "ph" into my address bar and thanks to Firefox
> hitting enter gets me to php.net, which in turn gives me everything
> that I need:
>
> -   The news are the main content and you want to put that on a separate
> page, calling it "Blog".
> Yes, most modern websites have a "Blog" instead of a "News" section,
> but that's because at some point it became "cool" for everyone to
> blog. There's no use to just naming it that when there's zero blogging
> going on and we have almost exclusively only release announcements.
>
> -   The ChangeLog I get convenienty linked to from each news article
> about a release (again that's all the news). So that's another thing
> you're taking away from the index page, even if by accident.
>
> -   The search bar allows me to check the manual for any function
> signature, built-in class reference, etc.
> Note that I said "search the manual" in my first reply, not browse
> it. I've never needed to visit php.net/documentation, yet that's what
> you suggest I should do.
>
> These things are regressions for me, not improvements.
>
>
> In essence, I share Rowan's sentiment in that I actually quite like
> the current website, but I like it because it is excellent for
> everyday lookups. As long as you can keep it that way, I fully support
> your effort.
> I don't really care about the design, but there's plenty of other
> stuff that could use some love.
>
> Cheers,
> Andrey.
>
> On Mon, Feb 4, 2019 at 5:14 PM azjezz azj...@protonmail.com wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, February 4, 2019 2:32 PM, Andrey Andreev n...@devilix.net 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 showi

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

Hi,

I was avoiding this, but since the discussion has already turned into
all about who gets to vote, I might as well ...

On Tue, Feb 5, 2019 at 1:46 AM Zeev Suraski  wrote:
> the barrier to obtaining a vote is ridiculously low.

You keep saying that, but it hasn't been explained how it is so.

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.

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.

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

Anyone who has ever attempted to use such metrics for evaluation would
tell you that commit count is a horrible one. It makes no difference
between 25 and 25k lines, quality or significance.
It doesn't give any weight to participation in discussions either,
whether its on this list or code reviews, both of which I believe are
influential and valuable.
Some squash commits, some don't; I've had my own commits squashed AND
authored by the person who merged them, meaning my name isn't attached
to them at all. This is an example of a previously meaningless factor
all of a sudden becoming a deciding one.
There are some well-known names that don't make the cut in Appendix A
and that does raise an eyebrow.

If you want to say that there are people with voting privileges that
haven't earned them, that's one thing, but (and I'm not assuming bad
intentions with this) as it stands it looks like you just wanted to
cut as much as possible and only looked for a metric that wasn't going
to eliminate the very top contributors, whom you can't afford to lose.

Cheers,
Andrey.

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

Hi,

On Mon, Feb 4, 2019 at 5:14 PM azjezz  wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, February 4, 2019 2:32 PM, 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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> >
> > 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.
> >
> > Cheers,
> > Andrey.
>
> The landing page is meant for the new comers to PHP, when people search for 
> php, the home page is the first to appear. it make sense to show a sample and 
> a straightforward button to get started with using PHP ( introduction, 
> installation and tutorial )
>

There's a missing link here - who searches for "php" without prior
knowledge of what it is? Programming languages aren't buzzwords that
come up in casual conversations between people who don't already use
them.

And how does it make sense to show a code sample? What for? The only
time I've seen isolated, meaningless code samples serve a purpose is
to look cool in movies.

Now that you mentioned a tutorial, that's one thing I agree is useful
and missing. As a self-learner myself, 15 years ago I would've
appreciated a vetted selection of tutorials on the official website.
But why not just put a "Tutorials" link alongside "Documentation"?

> You can see the mock up repository for what the "Getting Started" page would 
> look like.
>

No such thing had been linked until your last reply (which was sent
after I started writing this), but that's my point exactly - you have
to look at it first in order to know what's hiding behind it and
that's counter-productive to me; I reiterate the suggestion to have a
"Tutorials" link instead.

> if you usually visit the website for documentation, you would just type 
> php.net/documentation in the url bar instead of php.net or php.net/blog for 
> changelogs and articles.

See, this is where you actually make the site harder to use.

Today, I only type "ph" into my address bar and thanks to Firefox
hitting enter gets me to php.net, which in turn gives me everything
that I need:

- The news are the main content and you want to put that on a separate
page, calling it "Blog".
  Yes, most modern websites have a "Blog" instead of a "News" section,
but that's because at some point it became "cool" for everyone to
blog. There's no use to just naming it that when there's zero blogging
going on and we have almost exclusively only release announcements.

- The ChangeLog I get convenienty linked to from each news article
about a release (again that's all the news). So that's another thing
you're taking away from the index page, even if by accident.

- The search bar allows me to check the manual for any function
signature, built-in class reference, etc.
  Note that I said "search the manual" in my first reply, not browse
it. I've never needed to visit php.net/documentation, yet that's what
you suggest I should do.

These things are regressions for me, not improvements.

---

In essence, I share Rowan's sentiment in that I actually quite like
the current website, but I like it because it is excellent for
everyday lookups. As long as you can keep it that way, I fully support
your effort.
I don't really care about the design, but there's plenty of other
stuff that could use some love.

Cheers,
Andrey.

On Mon, Feb 4, 2019 at 5:14 PM azjezz  wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, February 4, 2019 2:32 PM, 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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> >
> > I just hate those useless landing pages.
> >
> > Yes, it looks neat and c

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

Den tir. 5. feb. 2019 kl. 02.22 skrev Kalle Sommer Nielsen :
> I agree with that as long as it is without the PHP Project boundaries,

s/without/within

-- 
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: RFC Workflow & Voting (2019 update)

Den tir. 5. feb. 2019 kl. 02.10 skrev Christoph M. Becker :
> 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.

I agree with that as long as it is without the PHP Project boundaries,
as the deciding vote is done by actual active PHP.net contributors.
For me the line about who within project can vote is up for
discussion, tho somewhere I feel it should be those with php-src karma
but I do believe anyone actively contributing to PHP as a project by
code should have the ability to vote in one way or another as a
privilege of continuous effect put into the project as a whole. I do
not believe the deciding factor should be in the hands of people
outside the project but that we as developers of the project HEARS
them and respect their voice while putting a sense of personal bias
aside like I replied to Larry in my first mail.

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

I think that is a healthy approach, and by reading parts of this RFC
it does sound like Zeev indeed did build on this. With the 3 current
threads we have going, despite a bit confusing, I do think we have
started to open up the can of worms that is our RFC process and slowly
work our way to see what we can do to improve that.

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

On Monday, February 4, 2019 5:11 PM, Thomas Hruska  
wrote:

> On 2/4/2019 6:32 AM, 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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> >
> > 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.
> > Cheers,
> > Andrey.
>
> I regularly go to thephp.net homepage for the live documentation search
> function just to make sure I'm using functions correctly. My most
> frequent search is the date() function for the % code list. One of
> these days I'll print out that docs page instead of looking it up every
> time to save everyone the bandwidth. Of the things I'd miss the most
> would be the live documentation search feature to jump directly to what
> I'm looking for. Google Search doesn't cut it here.
>
> For a newbie, I'd say a "Get Started" button that goes to a vetted group
> of starter tutorials (maybe videos?) on a variety of subjects could be
> valuable. I wouldn't want the homepage to load a video player though.
>
> My biggest complaint is that there's nothing in the mockup that says
> what PHP is for.
>
> Website: "Here's PHP spelled out and a difficult to comprehend code
> example. Uh...Get Started?"
>
> First time visitor: "Okay, that's great. Now tell me what is PHP in
> words I can understand and what can I use it for and is it popular?"
>
> A code example rarely, if ever, makes a good first impression.
>
> -
>
> Thomas Hruska
> CubicleSoft President
>
> I've got great, time saving software that you will find useful.
>
> http://cubiclesoft.com/
>
> And once you find my software useful:
>
> http://cubiclesoft.com/donate/


thanks for your suggestion, i have update the mock up to :

1. include a search input in the navbar
2. move the "Getting Started" button to the navbar
3. include a short description of what PHP is ( the same one that is currently 
on the of php.net )

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


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

On Monday, February 4, 2019 5:16 PM, Rowan Collins  
wrote:

> On Mon, 4 Feb 2019 at 15:19, azjezz  wrote:
>
>> I'm not proposing updating the UI and other websites to use, instead rebuild 
>> all PHP websites.
>
> I'm not sure what the difference between "updating the UI" and "rebuilding 
> the websites" is. Do you mean that as well as rewriting every HTML and CSS 
> template, you're going to build a completely new bug tracker, a new DocBook 
> to HTML generator for the manual, and so on? If so, I strongly suggest you 
> rein in your ambitions and tackle one problem at a time.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

i think i will start by php.net and the documentation. but this would also 
require markdown documentation, as contributing to the PHP docs is not easy at 
all now.
but this it another topic for another time.

for now, i'll just finish doing the mock ups.

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

2019-02-04 Thread Christoph M. Becker

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

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

2019-02-04 Thread Zeev Suraski

> -Original Message-
> From: Dan Ackroyd 
> Sent: Sunday, February 3, 2019 10:24 PM
> To: Zeev Suraski 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
> 
> On Sun, 3 Feb 2019 at 06:19, Zeev Suraski  wrote:
> >
> > On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd 
> wrote:
> >> Hi Zeev,
> >>
> >> Please can you very clearly state what problem you are trying to
> >> solve by changing the rules about who can vote.
> >
> > Fair enough, I've heard that question from several others.
> 
> I've read all 1200 words of your reply, which is quite a few words.
> 
> I still can't see a clear description of what problem you're trying to solve 
> by
> changing who can vote.

To summarize the issues (all written in my response):

- Voting rights today are assigned in a way that isn't consistent with our 
current Voting RFC, nor that was ever intended in any point.
- Due to an unintended consequence of a Wiki implementation detail, the barrier 
to obtaining a vote is ridiculously low.
- The current system has no parallels in the world of major OS projects - which 
I do view as a problem, as I don't think we're inherently different from every 
other major OS project out there.

I realize we now have some sort of status quo that we're used to, but it does 
not mean it's a sensible status quo.

> The reason I'm being pedantic about this, is that when people just discuss
> possible solutions to a vague sense of "this situation isn't perfect", they 
> will
> often suggest things that don't actually address the underlying problem. Or
> disagree about details that don't actually matter.
> 
> We really can't have a clear conversation about what to change without a clear
> description of the problem that ought to be solved.
> 
> For example, if the fundamental problem you are trying to address is that 
> it's too
> difficult for people to get a vote, then I would support documenting what our
> current system is, and allowing people to know what they need to do to acquire
> a vote. If the fundamental problem the RFC is trying to address, is to bring 
> in a
> whole load of new voters, who don't know how PHP works internally, then I
> wouldn't be as supportive.

I've been doing a horrible job at explaining myself if that's what you think 
I'm trying to do.  I'm certainly not trying to address a(n IMHO) non-existent 
problem that it's too difficult to get a vote, or getting a whole load of new 
voters.  Quite the opposite - I think we have way too many eligible voters 
today, roughly an order of magnitude greater than originally intended.  It's 
way too easy to obtain voting credentials, in a way that is, in my opinion, 
both problematic and unfair to the main contributors.  The goal is to go back 
to the original definition from 7.5 years ago, make it clearer (there's more 
work to be done here), and then stick to it - without letting implementation 
details in the Wiki be the judge of who gets to vote.  If we do it - the voting 
base will actually shrink from around two thousand today - perhaps even 
slightly more - to around 150-200.

To put things in perspective - there was quite some backlash regarding 
providing PHP-FIG with voting rights, which is an entirely valid opinion.  At 
the same time - any person that ever contributed to PEAR (and consequently has 
a php.net account) - has immediate full voting rights.  The fact of the matter 
is that out of the ~2000 users we have on php.net, less than 200 actually clear 
the bar set in the RFC (which isn't particularly high - 25 commits, 500 lines 
of code added/changed in the project).  Out of those, more than a thousand 
haven't submitted anything at all to php-src, but have potentially submitted to 
other php.net projects (e.g. PEAR, or the php.net website), and an additional 
~200 have affected fewer than 10 lines in php-src.  Personally, I think it does 
tell us something about the viability of the current voting qualifications, and 
I don't think what it's telling us is positive.

Whether or not contributions to php-src should be the only criteria by which we 
admit voters is a good question.  I'm personally still undecided on it - 
whether we should find a mechanism to admit non php-src contributors as voters 
(like folks from PHP-FIG, major PHP OS projects, etc.), or whether we should 
rely on their voices being heard in the discussions and then represented by the 
php-src contribs.  What I personally think is clear, though, that the awkward 
status quo we currently live in needs fixing - and it's a good time to do it, 
as we discuss other elements such as voting margins and workflow.

Zeev

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

Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield :
>
> It's not absurd, it's a matter of degrees.  As Zeev noted in a later email,
> the current voting RFC already calls for some voting-level input from "major
> customers", but not a controlling vote.
> To use hyperbolic examples:
>
> Would adding one single non-C-developer to the voting rolls mean that "the
> Core Developers have to maintain code that is decided by external, non
> contributing parties"?  No, that's "kinda absurd" to call it that, because
> that one voter is clearly swamped out by  the many other Internals developers
> that are also voting.

You and I both know the average turn-out of people voting here on
RFCs, that I do not doubt you follow in anyway and then you know that
if we add that top plus additional projects not represented under the
FIG, then that is a large deciding factor and don't tell me that
everyone who could get the ability by getting a vote won't be doing so
for at least the first long while. I do believe it will decrease over
time yes, but anytime soon if it passes.

> Would adding 200 non-C developers to the voting roll mean that?  Certainly
> yes, that would be an absurd situation.  But no one that I've seen is
> suggesting that at all, or anything close to it.

There has to a limit. Whether it is 1 or 200 or even 1000 doesn't
matter. As long as it is more than 0 externals that has a direct
deciding factor for a change. There is a fine line whether a non
project member should have a say in the voting which is apart of our
project management over actively listening and engaging with the
community and taking that feedback into shaping PHP. The line I'm
trying to write here in bold is that having a say doesn't mean voting
power by any means.

If you as userland believes that we as the language project do not
include your feedback, then let's have a discussion about that in a
thread and look at how we can make a more engaging and open way to
actively work on what the community would want to see coming into PHP.
I do not believe influence should be linked to voting power within the
project by any means, that is one of my main arguments against this.

> What's the threshold of absurdity here?  That we could debate.  However, it is
> not 0.  (I'd personally put it in the 10-20 range, bearing in mind that not
> all of them would vote all the time anyway, just like core developers, but
> others may feel differently.)

As long as a non project contributor, as have the power in the form of
being able to vote and therefore directly affect the active ones. That
is my threshold of absurdity and in a way I'm baffled that you do not
seem to understand that.

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

> That same point applies to any "invited outsiders", whether that's done
> through FIG or otherwise.  Per Zeev's email, it does seem like some mechanism
> for invited-outsiders was always intended, even if it never materialized.

Back then I was also against that, and I'm happy it didn't materialize
further on the voting aspect. This gives us a chance to clean this
system up and streamline the processes.

> To clarify: I last wrote C code in 2004 for Palm OS.  I am quite rusty; on top
> of that I know just enough about Internals to say that it's not as much
> written in C as it is in a macro language built in C, so the learning curve
> would be rather high.  My personal lack of involvement in actual Internals
> code is mainly because the logistical barrier to re-learning enough tooling
> and language to do so is too high given that I have no professional
> justification for it.  I try to contribute to the PHP ecosystem in other ways
> instead, internals or otherwise.
>
> Whether or not I am personally impacted, though, I do feel and have long felt
> that a more direct mechanism for user-land developers to have some influence
> on PHP would be beneficial.  (Though, yes, considerably less than the di

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Benjamin Eberlei

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

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?

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

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Benjamin Eberlei

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

>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Bruce Weirdan

After figuring out that opcache.jit_buffer_size is specified in bytes
(not in megabytes, as RFC states) I got ~5% speedup running
vimeo/psalm (static analyzer) on its own codebase with default
JIT flags and ~7.3% with minimal JIT (1201).

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

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

Re: [PHP-DEV] [RFC] JIT

On Mon, Feb 4, 2019 at 3:44 PM Nikita Popov  wrote:

> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  wrote:
>
>>
>>
>> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>> >
>> >
>> > On 2/1/19 3:09 PM, Nikita Popov wrote:
>> >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > >> > wrote:
>> >>
>> >>  Hi Internals,
>> >>
>> >>
>> >>  I'm glad to finally propose including JIT into PHP.
>> >>
>> >>
>> >>  https://wiki.php.net/rfc/jit
>> >>
>> >>
>> >>  In the current state it may be included both into PHP-8, where we
>> >>  are going to continue active improvement, and into PHP-7.4, as an
>> >>  experimental feature.
>> >>
>> >>
>> >>  Thanks. Dmitry.
>> >>
>> >>
>> >> I would like to check if the JIT provides an improvement for
>> PHP-Parser.
>> >> Unfortunately I'm getting a segfault when running the tests. Should be
>> >> reproducible with
>> >>
>> >> git clone g...@github.com:nikic/PHP-Parser.git
>> >> cd PHP-Parser
>> >> composer install
>> >> php-jit vendor/bin/phpunit
>> >>
>> >> I tried to debug this. Unfortunately my gdb doesn't seem to work with
>> >> JIT: It hangs when the script starts running, on line
>> Zend/zend_gdb.c:84
>> >> in zend_gdb_register_code. I don't know if that's a bug or I need to do
>> >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>> >> 8.1.0.20180409-git).
>> >
>> > GDB takes enormous time registering too many JIT-ed functions...
>> > It should be possible to catch the name of problematic functions and the
>> > JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
>> > most probably, only on next week.
>>
>> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
>> related to changes introduced by typed properties patch).
>>
>> I'm also going to disable automatic JIT code registration in GDB.
>>
>> Thanks. Dmitry.
>>
>
> Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
> speedup with default JIT configuration. That's promising :)
>

Unfortunately I made a mistake here and benchmarked against vanilla PHP
without opcache (and more importantly the optimizer in opcache). Here are
the correct results (for repeated parsing of a large file):

PHP: 3.7s
PHP+optimizer: 3.2s
PHP+optimizer+JIT: 2.4s

So the speedup is ~1.3x rather than ~1.5x, which is still good.

I also ran the hello-world.php example of
https://github.com/amphp/http-server against wrk -c100 -d30 -t4 and got the
following results:

PHP: 9950 rps
PHP+optimizer: 10750 rps
PHP+optimizer+JIT: 11350 rps

So in this case the improvement is about 5%. (This is the HTTP 1.1 server,
HTTP 2 would also be interesting to try, but needs some more setup.)

Nikita

Re: [PHP-DEV][RFC] Allow void return type variance

Hi Wes

Den man. 4. feb. 2019 kl. 05.19 skrev Wes :
>
> Hello PHPeeps!
>
> Recent events convinced me to write this RFC :P
>
> Please have a read here https://wiki.php.net/rfc/allow-void-variance
>
> I am targeting all the supported PHP versions because this is mainly to
> placate the discontent that arised by PHPUnit enforcing its users to use
> void, so waiting 7.4 doesn't make much sense.

I don't like to suddenly change things like that in lower versions. I
would be for it for 7.4, but not merging to already active releases
branches. That is usually not how we deal with things like this.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

[PHP-DEV] [VOTE] Making stdClass iterable

2019-02-04 Thread Craig Duncan

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

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi!

>> I want to say that even a small and fairly
> simple code change,
> which I proposed to push through the bureaucracy, was difficult.

> I think this is what Nikita wants to change with this simpler procedure.
> More RFCs even on smaller changes, so that more broad input can be
> gathered before doing any kind of change.

If so, this is IMO a bad idea. We don't need to make contributing
harder, and have a formal two-week vote on each change.
But, since the original quote talks about the past, then it can't be
about RFCs, because in the past we didn't require RFCs for small changes
(and shouldn't in the future).

-- 
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] Allow void return type variance

Hi!

> Recent events convinced me to write this RFC :P
> 
> Please have a read here https://wiki.php.net/rfc/allow-void-variance
> 
> I am targeting all the supported PHP versions because this is mainly to
> placate the discontent that arised by PHPUnit enforcing its users to use
> void, so waiting 7.4 doesn't make much sense.

I was never a big fan of void pseudotype, but since it exists, I think
it makes sense to be able to override it. It does not violate the
protocol (since it's impossible in PHP for function to not return a
value, and it's very implausible anybody relies on void function to
return null). And since we have users complaining, it makes sense to fix it.

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

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

Re: [PHP-DEV] [RFC] JIT



On 2/4/19 6:22 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/4/19 5:44 PM, Nikita Popov wrote:
>  > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  
>  > >> wrote:
>  >
>  >
>  >
>  >     On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>  >      >
>  >      >
>  >      > On 2/1/19 3:09 PM, Nikita Popov wrote:
>  >      >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> mailto:dmi...@zend.com>
>  >     >
>  >      >> 
>   >      >>
>  >      >>      Hi Internals,
>  >      >>
>  >      >>
>  >      >>      I'm glad to finally propose including JIT into PHP.
>  >      >>
>  >      >>
>  >      >> https://wiki.php.net/rfc/jit
>  >      >>
>  >      >>
>  >      >>      In the current state it may be included both into PHP-8,
>  >     where we
>  >      >>      are going to continue active improvement, and into
> PHP-7.4,
>  >     as an
>  >      >>      experimental feature.
>  >      >>
>  >      >>
>  >      >>      Thanks. Dmitry.
>  >      >>
>  >      >>
>  >      >> I would like to check if the JIT provides an improvement for
>  >     PHP-Parser.
>  >      >> Unfortunately I'm getting a segfault when running the tests.
>  >     Should be
>  >      >> reproducible with
>  >      >>
>  >      >> git clone g...@github.com:nikic/PHP-Parser.git
>  >      >> cd PHP-Parser
>  >      >> composer install
>  >      >> php-jit vendor/bin/phpunit
>  >      >>
>  >      >> I tried to debug this. Unfortunately my gdb doesn't seem
> to work
>  >     with
>  >      >> JIT: It hangs when the script starts running, on line
>  >     Zend/zend_gdb.c:84
>  >      >> in zend_gdb_register_code. I don't know if that's a bug or I
>  >     need to do
>  >      >> something additional here (I'm using GNU gdb (Ubuntu
> 8.1-0ubuntu3)
>  >      >> 8.1.0.20180409-git).
>  >      >
>  >      > GDB takes enormous time registering too many JIT-ed
> functions...
>  >      > It should be possible to catch the name of problematic
> functions
>  >     and the
>  >      > JIT only them (using PHPDOC trigger). I'll try to analyze the
>  >     crash, but
>  >      > most probably, only on next week.
>  >
>  >     I fixed the problem caused JIT to fail on PHP-Parser tests
> (it was
>  >     related to changes introduced by typed properties patch).
>  >
>  >     I'm also going to disable automatic JIT code registration in GDB.
>  >
>  >     Thanks. Dmitry.
>  >
>  >
>  > Thanks. I was now able to run a PHP-Parser benchmark, which
> showed ~1.5x
>  > speedup with default JIT configuration. That's promising :)
>  >
>  > Next I want to try https://github.com/amphp/hpack (part of HTTP 2
>  > implementation), where I also expect good results. Currently
> there is a
>  > segfault while running tests.
> 
> Could you provide a quick instruction, how to reproduce this (in the
> same way like with PHP-Parser).
> 
> 
> The reproduce steps are basically the same in this case, just on a 
> different repo:
> 
> git clone g...@github.com:amphp/hpack.git
> cd hpack
> composer install
> php-jit vendor/bin/phpunit
> 
> Nikita

Fixed.

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

2019-02-04 Thread Benjamin Eberlei

On Mon, Feb 4, 2019 at 9:00 AM Stanislav Malyshev 
wrote:

> Hi!
>
> >> I want to say that even a small and fairly
> > simple code change,
> > which I proposed to push through the bureaucracy, was difficult.
>
> We're discussing RFCs. Small and fairly simple code change does not need
> an RFC.


I think this is what Nikita wants to change with this simpler procedure.
More RFCs even on smaller changes, so that more broad input can be gathered
before doing any kind of change.


> So either:
>
> a) this change is indeed small and simple, and does not belong to the
> topic about RFC process, maybe about code review process, which is no
> less important, but different talk.
>
> b) this change wasn't as small and simple as it appeared, it did require
> the RFC, but you didn't know that. It's not your fault, no shame here -
> but this shows the process worked as it should have.
>
> > This, I am afraid is all too common. Many many times, while working
> through
> > github issues, I will be uncomfortable with making a merge for someone
> > without input from internals. I would tell that person to start a
> > discussion on internals and they would be flat ignored, their change dead
> > in the water, and their reason to continue contributing evaporates.
>
> But how this relates to RFCs? Certainly not every patch needs an RFC.
>
> --
> 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

2019-02-04 Thread Thomas Nunninger


Hi Thomas,

I regularly go to the php.net homepage for the live documentation search 
function just to make sure I'm using functions correctly.  My most 
frequent search is the date() function for the % code list.  One of 
these days I'll print out that docs page instead of looking it up every 
time to save everyone the bandwidth.  Of the things I'd miss the most 
would be the live documentation search feature to jump directly to what 
I'm looking for.  Google Search doesn't cut it here.


Try http://php.net/date

As long as you know the exact spelling of the method, that works 
perfectly. If you do not know exact spelling, perhaps you get some 
usable suggestions - more often not...


Regards

Thomas

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

2019-02-04 Thread Rowan Collins

On Mon, 4 Feb 2019 at 16:11, Thomas Hruska  wrote:

> For a newbie, I'd say a "Get Started" button that goes to a vetted group
> of starter tutorials (maybe videos?) on a variety of subjects could be
> valuable.
>

I know some people love them, but I absolutely hate video introductions. I
like to skim read content for the bits that are of use to me, and glance
back and forth to get the idea; videos don't let me do that. If a project
says "watch our 10- minute video to understand what we're all about", I
close the browser tab and go somewhere else. So if anyone goes down this
route, please make videos *supplement* a user-friendly text introduction,
not *replace* it.

Regards,
-- 
Rowan Collins
[IMSoP]

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

2019-02-04 Thread Rowan Collins

On Mon, 4 Feb 2019 at 15:19, azjezz  wrote:

> I'm not proposing updating the UI and other websites to use, instead
> rebuild all PHP websites.
>

I'm not sure what the difference between "updating the UI" and "rebuilding
the websites" is. Do you mean that as well as rewriting every HTML and CSS
template, you're going to build a completely new bug tracker, a new DocBook
to HTML generator for the manual, and so on? If so, I strongly suggest you
rein in your ambitions and tackle one problem at a time.

Regards,
-- 
Rowan Collins
[IMSoP]

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

2019-02-04 Thread Thomas Hruska

On 2/4/2019 6:32 AM, 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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67

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.

Cheers,
Andrey.

I regularly go to the php.net homepage for the live documentation search
function just to make sure I'm using functions correctly. My most
frequent search is the date() function for the % code list. One of
these days I'll print out that docs page instead of looking it up every
time to save everyone the bandwidth. Of the things I'd miss the most
would be the live documentation search feature to jump directly to what
I'm looking for. Google Search doesn't cut it here.

For a newbie, I'd say a "Get Started" button that goes to a vetted group
of starter tutorials (maybe videos?) on a variety of subjects could be
valuable. I wouldn't want the homepage to load a video player though.

My biggest complaint is that there's nothing in the mockup that says
what PHP is for.

Website: "Here's PHP spelled out and a difficult to comprehend code
example. Uh...Get Started?"

First time visitor: "Okay, that's great. Now tell me what is PHP in
words I can understand and what can I use it for and is it popular?"

A code example rarely, if ever, makes a good first impression.

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Eugene Leonovich

On Mon, Feb 4, 2019 at 3:45 PM Zeev Suraski  wrote:

> One our hopes in opening this up for comments, is that people would
> actually try the code themselves and experiment with it - well beyond what
> we can do ourselves.
>

Is there a docker image with JIT support that people can try?

Re: [PHP-DEV] [RFC] JIT

On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov  wrote:

>
>
> On 2/4/19 5:44 PM, Nikita Popov wrote:
> > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  > > wrote:
> >
> >
> >
> > On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> >  >
> >  >
> >  > On 2/1/19 3:09 PM, Nikita Popov wrote:
> >  >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  > 
> >  >> >> wrote:
> >  >>
> >  >>  Hi Internals,
> >  >>
> >  >>
> >  >>  I'm glad to finally propose including JIT into PHP.
> >  >>
> >  >>
> >  >> https://wiki.php.net/rfc/jit
> >  >>
> >  >>
> >  >>  In the current state it may be included both into PHP-8,
> > where we
> >  >>  are going to continue active improvement, and into PHP-7.4,
> > as an
> >  >>  experimental feature.
> >  >>
> >  >>
> >  >>  Thanks. Dmitry.
> >  >>
> >  >>
> >  >> I would like to check if the JIT provides an improvement for
> > PHP-Parser.
> >  >> Unfortunately I'm getting a segfault when running the tests.
> > Should be
> >  >> reproducible with
> >  >>
> >  >> git clone g...@github.com:nikic/PHP-Parser.git
> >  >> cd PHP-Parser
> >  >> composer install
> >  >> php-jit vendor/bin/phpunit
> >  >>
> >  >> I tried to debug this. Unfortunately my gdb doesn't seem to work
> > with
> >  >> JIT: It hangs when the script starts running, on line
> > Zend/zend_gdb.c:84
> >  >> in zend_gdb_register_code. I don't know if that's a bug or I
> > need to do
> >  >> something additional here (I'm using GNU gdb (Ubuntu
> 8.1-0ubuntu3)
> >  >> 8.1.0.20180409-git).
> >  >
> >  > GDB takes enormous time registering too many JIT-ed functions...
> >  > It should be possible to catch the name of problematic functions
> > and the
> >  > JIT only them (using PHPDOC trigger). I'll try to analyze the
> > crash, but
> >  > most probably, only on next week.
> >
> > I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> > related to changes introduced by typed properties patch).
> >
> > I'm also going to disable automatic JIT code registration in GDB.
> >
> > Thanks. Dmitry.
> >
> >
> > Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
> > speedup with default JIT configuration. That's promising :)
> >
> > Next I want to try https://github.com/amphp/hpack (part of HTTP 2
> > implementation), where I also expect good results. Currently there is a
> > segfault while running tests.
>
> Could you provide a quick instruction, how to reproduce this (in the
> same way like with PHP-Parser).
>

The reproduce steps are basically the same in this case, just on a
different repo:

git clone g...@github.com:amphp/hpack.git
cd hpack
composer install
php-jit vendor/bin/phpunit

Nikita

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





Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, February 4, 2019 2:02 AM, Levi Morrison  wrote:

> On Sun, Feb 3, 2019 at 5:15 PM azjezz azj...@protonmail.com 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 https://azjezz.github.io
>
> 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.

I'm not proposing updating the UI and other websites to use, instead rebuild 
all PHP websites.

for the mock-ups, i have created a GitHub repository : 
https://github.com/azjezz/web-php-mock-ups/

this would take more time than just updating the UI, but the PHP website is 
getting old and most of it is broken or just hard to use.

i would appreciate any help or suggestions for the UI.
as it would be the first step before starting to build the new website.

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



‐‐‐ Original Message ‐‐‐
On Monday, February 4, 2019 2:32 PM, 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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
>
> 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.
>
> Cheers,
> Andrey.

The landing page is meant for the new comers to PHP, when people search for 
php, the home page is the first to appear. it make sense to show a sample and a 
straightforward button to get started with using PHP ( introduction, 
installation and tutorial )

You can see the mock up repository for what the "Getting Started" page would 
look like.

if you usually visit the website for documentation, you would just type 
php.net/documentation in the url bar instead of php.net or php.net/blog for 
changelogs and articles.

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

Re: [PHP-DEV] [RFC] JIT



On 2/4/19 5:44 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>  >
>  >
>  > On 2/1/19 3:09 PM, Nikita Popov wrote:
>  >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  
>  >> >> wrote:
>  >>
>  >>      Hi Internals,
>  >>
>  >>
>  >>      I'm glad to finally propose including JIT into PHP.
>  >>
>  >>
>  >> https://wiki.php.net/rfc/jit
>  >>
>  >>
>  >>      In the current state it may be included both into PHP-8,
> where we
>  >>      are going to continue active improvement, and into PHP-7.4,
> as an
>  >>      experimental feature.
>  >>
>  >>
>  >>      Thanks. Dmitry.
>  >>
>  >>
>  >> I would like to check if the JIT provides an improvement for
> PHP-Parser.
>  >> Unfortunately I'm getting a segfault when running the tests.
> Should be
>  >> reproducible with
>  >>
>  >> git clone g...@github.com:nikic/PHP-Parser.git
>  >> cd PHP-Parser
>  >> composer install
>  >> php-jit vendor/bin/phpunit
>  >>
>  >> I tried to debug this. Unfortunately my gdb doesn't seem to work
> with
>  >> JIT: It hangs when the script starts running, on line
> Zend/zend_gdb.c:84
>  >> in zend_gdb_register_code. I don't know if that's a bug or I
> need to do
>  >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>  >> 8.1.0.20180409-git).
>  >
>  > GDB takes enormous time registering too many JIT-ed functions...
>  > It should be possible to catch the name of problematic functions
> and the
>  > JIT only them (using PHPDOC trigger). I'll try to analyze the
> crash, but
>  > most probably, only on next week.
> 
> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> related to changes introduced by typed properties patch).
> 
> I'm also going to disable automatic JIT code registration in GDB.
> 
> Thanks. Dmitry.
> 
> 
> Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x 
> speedup with default JIT configuration. That's promising :)
> 
> Next I want to try https://github.com/amphp/hpack (part of HTTP 2 
> implementation), where I also expect good results. Currently there is a 
> segfault while running tests.

Could you provide a quick instruction, how to reproduce this (in the 
same way like with PHP-Parser).

Thanks. Dmitry.

> 
> Nikita

Re: [PHP-DEV] [RFC] JIT



On 2/4/19 1:32 PM, Andrea Faulds wrote:
> Dmitry Stogov wrote:
>> Hi Internals,
>>
>>
>> I'm glad to finally propose including JIT into PHP.
>>
>>
>> https://wiki.php.net/rfc/jit
>>
>>
>> In the current state it may be included both into PHP-8, where we are 
>> going to continue active improvement, and into PHP-7.4, as an 
>> experimental feature.
>>
>>
>> Thanks. Dmitry.
>>
> 
> Hi Dmitry,
> 
> Thank you for making an RFC for this. That makes it possible to have a 
> proper discussion about the JIT idea.
> 
> A concern I have with the current RFC is a lack of a good case for why 
> it should be necessary; the case for JIT is based on performance 
> benefits, but the examples provided are unconvincing to me because they 
> seem too contrived. Both bench.php and drawing fractals represent a 
> best-case example for a JIT, small programs which do heavy arithmetic 
> and not much else. Maybe PHP being able to be used for this kind of 
> software would be cool, but it wouldn't justify the added complexity 
> (and for that matter security headaches) of adding a JIT to PHP given C, 
> C++, FORTRAN and so on already exist and are better-suited to it.
> 
> I guess what I am saying is that the JIT RFC could benefit from 
> real-world examples that show a benefit to having it. The ideal 
> application is something in between WordPress and your Mandelbrot 
> example, one which has significant complexity (i.e. a plausible 
> real-world application), hot code which a JIT can actually make notably 
> faster than the current Zend VM, and is something not *too* far away 
> from the kinds of applications people write in PHP today — even if you 
> *could* write applications focussed on high-performance heavy 
> number-crunching in PHP, I don't expect people would want to, even if it 
> becomes less slow.

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

Thanks. Dmitry.

> 
> Thanks,
> Andrea
> 

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

Re: [PHP-DEV] [RFC] JIT

On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  wrote:

>
>
> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> >
> >
> > On 2/1/19 3:09 PM, Nikita Popov wrote:
> >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov  >> > wrote:
> >>
> >>  Hi Internals,
> >>
> >>
> >>  I'm glad to finally propose including JIT into PHP.
> >>
> >>
> >>  https://wiki.php.net/rfc/jit
> >>
> >>
> >>  In the current state it may be included both into PHP-8, where we
> >>  are going to continue active improvement, and into PHP-7.4, as an
> >>  experimental feature.
> >>
> >>
> >>  Thanks. Dmitry.
> >>
> >>
> >> I would like to check if the JIT provides an improvement for PHP-Parser.
> >> Unfortunately I'm getting a segfault when running the tests. Should be
> >> reproducible with
> >>
> >> git clone g...@github.com:nikic/PHP-Parser.git
> >> cd PHP-Parser
> >> composer install
> >> php-jit vendor/bin/phpunit
> >>
> >> I tried to debug this. Unfortunately my gdb doesn't seem to work with
> >> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
> >> in zend_gdb_register_code. I don't know if that's a bug or I need to do
> >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
> >> 8.1.0.20180409-git).
> >
> > GDB takes enormous time registering too many JIT-ed functions...
> > It should be possible to catch the name of problematic functions and the
> > JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
> > most probably, only on next week.
>
> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> related to changes introduced by typed properties patch).
>
> I'm also going to disable automatic JIT code registration in GDB.
>
> Thanks. Dmitry.
>

Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
speedup with default JIT configuration. That's promising :)

Next I want to try https://github.com/amphp/hpack (part of HTTP 2
implementation), where I also expect good results. Currently there is a
segfault while running tests.

Nikita

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Zeev Suraski

On Mon, Feb 4, 2019 at 12:33 PM Andrea Faulds  wrote:

> A concern I have with the current RFC is a lack of a good case for why
> it should be necessary;

While this is a subjective opinion, it's definitely a valid one.  Unlike
phpng (PHP 7) which was a slam dunk - JIT isn't - and whether or not the
added value is worth the added complexity is very much up for debate.

One our hopes in opening this up for comments, is that people would
actually try the code themselves and experiment with it - well beyond what
we can do ourselves.  If & when we get feedback from folks on apps and use
cases they tried this on with interesting results, we'll add them to the
RFC.  I'd love to hear from folks trying it on things like React.  Then,
there's also the possibility of writing builtin functions in PHP - although
that would obviously require a much wider platform support than we
presently have to be viable.

> and not much else. Maybe PHP being able to be used for this kind of
> software would be cool, but it wouldn't justify the added complexity
> (and for that matter security headaches) of adding a JIT to PHP given C,
> C++, FORTRAN and so on already exist and are better-suited to it.
>

This too is a subjective (& obviously completely valid) opinion.  Of
course, if the only point of JIT would be 'coolness' then it's probably not
worth the trouble (although JIT is a huge selling point even if it doesn't
bring huge gains, as we've seen in the past).  But I don't think it'll end
just there.  For me, I would prefer using PHP over any of these if I can
help it and if the performance is reasonable enough - and I doubt I'm the
only person on the planet that feels that way.  Again, we don't think it's
a slam dunk (the RFC would have looked differently if we did), but it's not
inconceivable that if we position PHP as a language where you can get the
ease of development benefits of PHP, while getting near-native performance
- it will open the door to new audiences.

Zeev

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

2019-02-04 Thread Rowan Collins

On Mon, 4 Feb 2019 at 13:33, Andrey Andreev  wrote:

>
> 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 agree with not needing a splashy home page (that makes me think 1990s,
"click to enter", rather than modern), although I'd point out you already
need to click through for two of the three tasks you name. Maybe there
should actually be a section on the homepage with links to the main manual
sections, as well as the most recent news stories?

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.

Regards,
-- 
Rowan Collins
[IMSoP]

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

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/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67

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.

Cheers,
Andrey.

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

Re: [PHP-DEV] Re: RFC Weakrefs

2019-02-04 Thread Michael Wallner

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



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] JIT



On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> 
> 
> On 2/1/19 3:09 PM, Nikita Popov wrote:
>> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > > wrote:
>>
>>  Hi Internals,
>>
>>
>>  I'm glad to finally propose including JIT into PHP.
>>
>>
>>  https://wiki.php.net/rfc/jit
>>
>>
>>  In the current state it may be included both into PHP-8, where we
>>  are going to continue active improvement, and into PHP-7.4, as an
>>  experimental feature.
>>
>>
>>  Thanks. Dmitry.
>>
>>
>> I would like to check if the JIT provides an improvement for PHP-Parser.
>> Unfortunately I'm getting a segfault when running the tests. Should be
>> reproducible with
>>
>> git clone g...@github.com:nikic/PHP-Parser.git
>> cd PHP-Parser
>> composer install
>> php-jit vendor/bin/phpunit
>>
>> I tried to debug this. Unfortunately my gdb doesn't seem to work with
>> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
>> in zend_gdb_register_code. I don't know if that's a bug or I need to do
>> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>> 8.1.0.20180409-git).
> 
> GDB takes enormous time registering too many JIT-ed functions...
> It should be possible to catch the name of problematic functions and the
> JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
> most probably, only on next week.

I fixed the problem caused JIT to fail on PHP-Parser tests (it was 
related to changes introduced by typed properties patch).

I'm also going to disable automatic JIT code registration in GDB.

Thanks. Dmitry.

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

Re: [PHP-DEV][RFC] Allow void return type variance

On Mon, 4 Feb 2019 at 13:28, Wes  wrote:

> I know this too. I am often in touch with Levi and void variance is not
> covered by his RFC
> As a matter of fact, if you try to compile that PR void will behave exactly
> like it does now
>

First of all, apologies as I needed a brush up on the difference between
general variance and covariance.
In fact, the RFC linked does not cover the variance of the void type.

> My RFC targets 7.2 and 7.3 other than 7.4
>

Secondly, I am nearly certain, but I would love to be proven wrong, that
new features aren't backported to older PHP releases.
So even then I don't think this will land in PHP 7.2/7.3

Now back to the proposal of the variance of void type.
I'm not sure I see the point of it?
Let me explain: if I define a method as void it means that it does stuff
which doesn't/can't return a sensible value.
Also, I am defining behavior and changing the return type, at least to me,
is a change in behavior.
Because a function/method which clearly is not intended to be used as a
value can now under your proposal become one.
Sure you can say that the return value may be only used by the child class
but if I want to change my parent class to this child class
I can't be sure that it will behave as before because *maybe* the child
class needs the return value of this previously void method.

Maybe I am just overthinking this however in my opinion if a return type
needs to be changed from void to something you are trying to
add behavior to a method which *probably* should go into its own method.

Best regards

George P. Banyard

Re: [PHP-DEV] Disable PEAR by default

2019-02-04 Thread Zeev Suraski

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

Re: [PHP-DEV][RFC] Allow void return type variance

2019-02-04 Thread Wes

I know this too. I am often in touch with Levi and void variance is not
covered by his RFC
As a matter of fact, if you try to compile that PR void will behave exactly
like it does now
My RFC targets 7.2 and 7.3 other than 7.4

>

Re: [PHP-DEV][RFC] Allow void return type variance

I know this, I am talking about this RFC
https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters
Which has been voted and implementation is being worked on a GitHub PR:
https://github.com/php/php-src/pull/3732

Your proposal doesn't bring anything new to the table that this RFC does.
Moreover, your RFC targets the same PHP version as the
covariant/contravariant RFC.

So like said before the issue which your RFC tries to address is already
being fixed.

Also, there is no need to upgrade to PHPUnit 8 and if people want to there
is a PHP_CS_FIXER sniff which can add void return types.
Namely: void_return

George P. Banyard

On Mon, 4 Feb 2019 at 13:03, Wes  wrote:

> Covariance from no-type is already supported, since 7.0
> https://3v4l.org/I1hZs
>

Re: [PHP-DEV][RFC] Allow void return type variance

2019-02-04 Thread Wes

Covariance from no-type is already supported, since 7.0
https://3v4l.org/I1hZs

Re: [PHP-DEV][RFC] Allow void return type variance

This is normal the Covariance/Contravariance is coming in PHP 7.4 not
before.
This RFC would also target PHP 7.4 so I don't see how this RFC would change
the PHPUnit problem.

George P. Banyard

On Mon, 4 Feb 2019 at 12:54, Wes  wrote:

> Nope, it's not. https://3v4l.org/N4LNb It should've been fixed.
> Indeed, many people expected it to work already.
>

Re: [PHP-DEV][RFC] Allow void return type variance

2019-02-04 Thread Wes

Nope, it's not. https://3v4l.org/N4LNb It should've been fixed.
Indeed, many people expected it to work already.

Re: [PHP-DEV][RFC] Allow void return type variance

Isn't this "fixed" with the Covariance/Contravariance RFC which has been
voted recently

George P. Banyard


On Mon, 4 Feb 2019 at 08:58, Wes  wrote:

> Hi!
>
> PHPUnit 8 changed e.g.  `  function setUp(){}` to  `  function setUp():
> void{} `   and a lot of people did not like being forced to do the same on
> their  `setUp()`.
>
> The issue is not PHPUnit adding `void`, but PHP forcing `void` even when
> it's not necessary. If PHPUnit wants to use void but inheritors don't want
> to, it should just be possible.
>
> "probably a bad idea" is opinionated, in reality there is no provable
> reason to disallow it, from a pure type-theory standpoint.
>

[PHP-DEV] Re: RFC Weakrefs

2019-02-04 Thread Andrea Faulds


Hi Joe,

I like the idea of adding weak references to the PHP core (as opposed to 
PECL), so I'm generally in favour of this RFC. This type of feature 
which the engine must be aware of should be maintained as part of it — 
and it not requiring a PECL extension means it can actually be used by 
much more code.


Have you considered adding a WeakMap type as well — a map of (object) 
keys to values where the keys are weakly referenced? This is a useful 
construct based on weak references and something I'm sure will be 
wanted. It could in theory be implemented in userland on top of your 
proposal, but it would be nice to save userland having to reimplement it 
(probably multiple times), and userland could be saved the problem of 
manually cleaning up now-dead weak references (annoyingly O(n)) and 
deciding when to do so — an internal implementation can handle it 
automagically and more performantly. :)


I do predict one potentially annoying part of implementing a WeakMap 
though: you could insert a value which has a destructor and then observe 
when keys are destructed. But it's not like destructors are a new 
problem in PHP.


Thanks,
Andrea

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

Re: [PHP-DEV] [RFC] JIT

2019-02-04 Thread Andrea Faulds


Dmitry Stogov wrote:

Hi Internals,


I'm glad to finally propose including JIT into PHP.


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


In the current state it may be included both into PHP-8, where we are going to 
continue active improvement, and into PHP-7.4, as an experimental feature.


Thanks. Dmitry.



Hi Dmitry,

Thank you for making an RFC for this. That makes it possible to have a 
proper discussion about the JIT idea.


A concern I have with the current RFC is a lack of a good case for why 
it should be necessary; the case for JIT is based on performance 
benefits, but the examples provided are unconvincing to me because they 
seem too contrived. Both bench.php and drawing fractals represent a 
best-case example for a JIT, small programs which do heavy arithmetic 
and not much else. Maybe PHP being able to be used for this kind of 
software would be cool, but it wouldn't justify the added complexity 
(and for that matter security headaches) of adding a JIT to PHP given C, 
C++, FORTRAN and so on already exist and are better-suited to it.


I guess what I am saying is that the JIT RFC could benefit from 
real-world examples that show a benefit to having it. The ideal 
application is something in between WordPress and your Mandelbrot 
example, one which has significant complexity (i.e. a plausible 
real-world application), hot code which a JIT can actually make notably 
faster than the current Zend VM, and is something not *too* far away 
from the kinds of applications people write in PHP today — even if you 
*could* write applications focussed on high-performance heavy 
number-crunching in PHP, I don't expect people would want to, even if it 
becomes less slow.


Thanks,
Andrea

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

Re: [PHP-DEV] Re: RFC Weakrefs

2019-02-04 Thread Andrea Faulds


Hello,

Joe Watkins wrote:

Already taken care of :)

On a side note, at what point do we remove stuff from the manual/pecl, the
weakref is extension is dead, can't work with current versions of PHP, and
there was never a stable release ?

I'm not even sure we have a mechanism to delete stuff from pecl ... there's
probably quite a lot of junk on there ...

Cheers
Joe


The situation with PECL in the PHP manual has bothered me for a while. I 
don't know (maybe I could find out) the reasons for mixing PECL and 
bundled extensions together in one manual, but considering the confusion 
it can creates and the undue prominence it gives (obscure 
poorly-maintained PECL extensions get the same accessibility as strlen, 
which can make PHP look bad as it seems like stuff like runkit is part 
of the language…) I would be in favour of splitting the PECL extensions 
into their own manual, or doing what some other languages do and just 
let each extension have its own documentation to itself.


Thanks,
Andrea

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

2019-02-04 Thread Ivan Enderlin


Hello and thanks for the RFC.

I think the Eligible Voters Section is too complex to be 
addressed/bundled in this RFC. I think it deserves another RFC.


Most discussions here are rightfully about this section. To add my opinion:

 * I don't understand the special treatment for PHP-FIG. This group
   first intent was to reflect the “major implementors point of view”
   in order to make common agreements/standards about some practises.
   Based on that, yes it makes sense to include PHP-FIG into the
   Eligible Voters group. However, some projects have decided to step
   away from PHP-FIG for various reasons I won't list here (I can
   mention sabre.io or hoa-project.net because I was/am involved in
   those projects). Thus, they are excluding themselves from the
   Eligible Voters group? It doesn't make sense, and it does not sound
   very democratic :-).
 * Some people don't contribute to the php-src repository (like
   myself), but create extensions, participate to the ecosystem, or
   push PHP further. As an example not related to myself, I think of
   PHPStan or Doctrine, both projects are important PHP projects, with
   an extreme usage of PHP features as a language, and their authors
   are in a good position to give feedbacks on PHP RFC, or to write
   ones. The metrics that are currently listed in the RFC to be an
   Eligible Voter entirely exclude this population. If this population
   is excluded, I'm afraid that the PHP future will defer from the real
   usages/expectations of the language.
 * I don't understand why keeping existing voters is an issue, it's not
   motivated, and consequently I can only disagree with the
   grandfathering section.

The rest of the RFC is very interesting. It would be sad to miss it 
because of the Eligible Voters Section. I suggest to split it into 2 RFC.


Regards.

On 31.01.19 14:44, Zeev Suraski wrote:

Without further ado, an RFC that’s attempting to comprehensively solve many of 
the issues that have plagued our RFC process since it was hastily introduced in 
2011:

  


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

  


Emphasis on ‘attempting’.  I’m sure there are still a lot of holes in it that 
should be plugged before we vote on it, but instead of waiting indefinitely – 
I’d like us to start discussing it.

  


Comments and suggestions welcome.

  


Zeev

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

Hi!

> What's the threshold of absurdity here?  That we could debate.  However, it 
> is 
> not 0.  (I'd personally put it in the 10-20 range, bearing in mind that not 
> all of them would vote all the time anyway, just like core developers, but 
> others may feel differently.)

I am not sure defining it in numeric terms is the correct approach.
After all, the RFC doesn't say now "20 non-C developers", it says
"PHP-FIG members". We have no control (and no desire to control) what
that means, but we pre-commit to giving all these people, whoever they
are and will be, voting rights now and forever in the future. I'm not
sure that's the right approach.
In fact, I'm also not sure "20 non-C developers" would be the right
approach - why specifically 20? What if we need 21? What if we can't
find even 10 who are really qualified? (all hypothetical of course) That
just sounds so arbitrary.
So I think we need to find something that doesn't look arbitrary and
doesn't look like putting voting eligibility in the project outside of
project members' control.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] JIT

On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov  wrote:

>
>
> On 2/3/19 9:00 PM, Nikita Popov wrote:
> > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:
> >
> >>
> >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> >>>
> >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
> 
> 
>  How is that related?
> >>>
> >>> It is directly related with your statement that "developers with other
> >>> host OSs still use Linux for the actual PHP development". They don't
> use
> >>> Linux for the actual PHP development. They are using Windows.
> >>
> >> That statement was in a certain context - for those who use containers
> and
> >> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
> >> that I'm not claiming it's everyone, or even the majority - but if it
> >> wasn't clear - it should be now...
> >>
> >> Zeev
> >>
> >
> > I feel like this discussion ended up going a bit astray, with a focus on
> > only the issue of Windows support... While I think that we should
> endeavor
> > to support at least Windows and MacOS before the JIT hits a release
> version
> > of PHP, at this point in time (and for the purposes of the vote) the
> > questions of maintenance and stability are the most important.
>
> If we don't start, we definitively won't get support.
>
>
> > Ultimately
> > those questions can't really be answered until interested parties have
> > reviewed the JIT codebase. To that end it would be helpful if:
> >
> > a) A PR of the JIT branch could be submitted against php-src, so there
> is a
> > place for review comments and more technical discussions. (It might be
> > necessary to squash, as GH doesn't deal with large history well.)
>
> OK. Not sure about re-base.
>
> > b) The RFC (or some other place) is extended with some high-level design
> > information on how the JIT works on a technical level. Some notes on how
> > JIT bugs are usually debugged would also be very helpful.
>
>
> OK. I'll try to extend RFC with some design elements.
>
> Thanks. Dmitry.
>

Thanks! Looks like the PR is here: https://github.com/php/php-src/pull/3792

Also, Joe has put up the JIT branch on the r11 lxr, which should make
browsing the code easier:
https://lxr.room11.org/xref/php-src%40jit/ext/opcache/jit/

Nikita

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

Hi!

Reading the RFC, here's my thoughts:

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.

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.

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.

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.

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.

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

7. For the sake of clarity, we should define what 2/3 threshold means -
is it:
a) $voted_yes >= 2 * $voters / 3
b) $voted_yes > 2 * $voters / 3
c) $voted_yes >= floor(2 * $voters / 3) + 1
d) something else?

8. 6 months seems a bit too long for rejected RFC. I'd probably shorten
it to something like 2 months, maybe even less. But include the language
that the feedback provided on the previous discussion stage should be
addressed (of course we can't control it, but we can establish the norm).

9. I'm not sure I understand the purpose of "RFCs that targeted the next
mini version, and are moved back to the Discussion Stage after a
Hibernation Period, may not target that same mini version" - why not?

10. I like the idea of no discussion during vacation time - though,
frankly, I've been using some vacation days to catch up with Internals
in the past...

11. 5 people to object to restart vote looks relatively high, and in
fact the procedure looks rather complicated... Is it a frequent
occurrence that needs special mention?

12. I think we need more work on eligibility criteria. Specifically, I
think we should aim for:
a) including everybody who made contribution to PHP project in the past,
if their contribution are recent or they plan to keep contributing
(simple public declaration of intent should be enough). I am not sure
yet if we need minimal conribution size - depends on whether it actually
changes anything or not (should we make some tools that allow us to see
what changes with and without minima?). I think the process should be
biased to the side of inclusion - one more voter wouldn't hurt, but one
person unjustly excluded from voting would feel very bad and it may lead
to bitter discussions that don't help anything.
b) including important non-code contributors
c) having the mechanism to periodically remove participants that have
left the project and have no intent to contribute anymore, and to
restore their voting eligibility if they come back
d) as I said before, I certainly do not feel comfortable with including
all 50-strong PHP-FIG membership, and all future members, given that we
have no say about how they are selected. We may want to think about
mechanism to include their feedback somehow but current proposal seems
to broad.

13. Quorum question would be an interesting one to tackle. Some votes
are being decided by very low number of votes, however I am not sure
whether or not it's a problem...

Probably will have more, but it's long enough for now :)
Also, I realize the above has a bit of a negative tint because I have
mostly addressed things that I disagree with or think may be improved,
so I want to explicitly state that I think it's great we are discussing
these things, and explicitly thank Zeev for working on it.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] phpenmod/phpdismod

Hi!

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

Enabling/disabling extensions can be useful for many scenario, both in
testing and development - such as testing various branches of code, see
proper error handling, etc. However, in my opinion, such scripts can be
in core only if they can be made to work in all or overwhelming majority
of deployments, which doesn't seem to be the case here.

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

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

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process