Re: [PHP-DEV] [RFC] JIT

Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller : > Shouldn't we introduce annotations instead of relying on doc comments? Yeah I'm not too happy with that approach either. I would rather see another way to do this and like you said; annotations is probably the best way to go about it as

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

On 05/02/2019 17:32, Tom Worster wrote: I have two suggestions, assuming you proceed roughly as outlined in your original post. 1. Start with /community A new community website [4], it can be a place for people to ask questions and discuss php in general - no one uses IRC anymore. Like

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

I can do some design, I designed the UI of CakePHP framework generators in 2015. You can see the whole process here: https://github.com/cakephp/cakephp/issues/6679 We should not rely on any css, js or html framework in my opinion. But it's up to you. For layout, CSS Grid and Flexbox is more

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

On 05.02.2019 at 18:51, Stanislav Malyshev wrote: >> “Inactive”[1] is likely what you're looking for. > > Inactive implies it's not being worked on... But we certainly could move > there at least ones that are "in discussion" for 2 years. The description of the section is “This section is for

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

On Tuesday, February 5, 2019 8:51 PM, Rowan Collins wrote: > On 05/02/2019 17:32, Tom Worster wrote: > > > I have two suggestions, assuming you proceed roughly as outlined in > > your original post. > > > > 1. Start with /community > > > > > A new community website [4], it can be a place for

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

Hi Nikita, Nikita Popov wrote: I'd like to bring forward the following proposal for PHP 8, which will make (zpp) parameter parsing failures always result in a TypeError (rather than generating a warning+null, depending on circumstances): https://wiki.php.net/rfc/consistent_type_errors I like

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

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

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

On Tuesday, February 5, 2019 8:49 PM, Midori Koçak wrote: > I can do some design, I designed the UI of CakePHP framework generators in > 2015. You can see the whole process here: > https://github.com/cakephp/cakephp/issues/6679 > > We should not rely on any css, js or html framework in my

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

On Tue, Feb 5, 2019 at 7:19 PM Nikita Popov wrote: > On Tue, Feb 5, 2019 at 5:55 PM Zeev Suraski wrote: > >> On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov wrote: >> >>> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov >>> wrote: >>> >>> >>> I'd like to move forward with this change. I think the

Re: [PHP-DEV] [RFC] JIT

Hi, Dmitry Stogov wrote: I've added info from Nikita: PHP-Parser became 1.5 times faster. That is actually a very good real-world example from my perspective and makes a better case for why JIT compilation to native code would be beneficial. I would like to write a PHP compiler in PHP

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

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

Re: [PHP-DEV] [RFC] JIT

I’m not sure it’s a great real-world example - PHP Parser is much more maths-y than the vast amount of PHP code, but if your PHP-based compiler had a similar makeup it might show somewhat similar benefits. > On Feb 5, 2019, at 8:47 PM, Andrea Faulds wrote: > > Hi, > > Dmitry Stogov wrote: >>

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

Looking at the Voting Eligibility discussion going on at the moment. I, like many others, participated in the last testfest 18 months or so ago. Did the results from that ever get merged? Or have they simply been discarded or forgotten? If merged, they certainly don't show up in the

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

Hi Nikita https://wiki.php.net/rfc/consistent_type_errors Would it make sense and be possible to trigger a deprecation notice in PHP 7.4? That might help the ecosystem move forward in a smooth way instead of experimenting the failure when actually moving to 8. Nicolas

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

Hello, On Wed, 6 Feb 2019 at 01:37, 苏晞 <2823324...@qq.com> wrote: > > What the hell are you fucking talk about ,beaches -- 原始邮件 > -- If I'd run this mailing list, you'd get a several weeks to months mute now. But luckily that's not the case. Read the mailing

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

Hello, On Wed, 6 Feb 2019 at 08:13, Mark Baker wrote: > > Looking at the Voting Eligibility discussion going on at the moment. > > I, like many others, participated in the last testfest 18 months or so > ago. Did the results from that ever get merged? Or have they simply been > discarded or

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

This is truly developer way. :-) On Feb 5, 2019 01:10, "Christoph M. Becker" wrote: > > On 04.02.2019 at 23:59, Kalle Sommer Nielsen wrote: > > > Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield > > : > > > >> To answer both you and Sanislav here together, as he raised a similar > >>

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

Le lundi 4 février 2019, 14:44:31 CET Rowan Collins a écrit : > In general, though, I quite like the current site design, and would much > rather effort was spent iteratively improving it, rather than throwing it > away and implementing a new set of bugs. > > My personal annoyance is the search

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

Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit : > Regardless of what you did, actually obtaining full voting rights > meant you had to ask for a VCS account, and have a reasonably good > explanation on why you need one - enough to convince one of the folks > with admin rights on

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

Hello, What is the usecase for this? The RFC does not explain what it would be useful for. json_decode already provides an option for getting arrays instead of objects. All in all the RFC does not provide enough information. As I understand it if stdClass is Traversable then all objects are,

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

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

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

On Tue, Feb 5, 2019 at 11:07 AM Côme Chilliet wrote: > Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit : > > Regardless of what you did, actually obtaining full voting rights > > meant you had to ask for a VCS account, and have a reasonably good > > explanation on why you need one -

Re: [PHP-DEV] Simplify license headers

On Mon, 4 Feb 2019, 02:32 Peter Kokot On Wed, 30 Jan 2019 at 13:57, Derick Rethans wrote: > > > > On Mon, 28 Jan 2019, Zeev Suraski wrote: > > > > > > > > > I would like to make two changes to this header: > > > > > > > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity > of

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

Hi internals, I'd like to bring forward the following proposal for PHP 8, which will make (zpp) parameter parsing failures always result in a TypeError (rather than generating a warning+null, depending on circumstances): https://wiki.php.net/rfc/consistent_type_errors The goal here is to remove

Re: [PHP-DEV] [RFC] JIT

On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov wrote: > > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei > > wrote: > > > > > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov >

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

On Tue, Feb 5, 2019 at 12:09 PM Andrey Andreev wrote: > Hi again, > > On Tue, Feb 5, 2019 at 10:37 AM Zeev Suraski wrote: > > > > Regardless of what you did, actually obtaining full voting rights > > meant you had to ask for a VCS account, and have a reasonably good > > explanation on why you

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

wt., 5 lut 2019 o 04:32 azjezz napisał(a): > ... > mock ups : https://github.com/azjezz/web-php-mock-ups > screenshot : > https://github.com/azjezz/web-php-mock-ups/blob/master/screenshots/getting-started.png > Is this your desired look you wanna propose? I may misunderstand and probably am. I

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

On Mon, Feb 4, 2019 at 10:56 AM Stanislav Malyshev wrote: > Hi! > > Reading the RFC, here's my thoughts: > Thanks for the detailed response! > 1. Do we really need different classification of changes? I think having > one single vote procedure would have larger benefit, and RFC that fails >

Re: [PHP-DEV] [RFC] JIT

On Tue, Feb 5, 2019 at 11:45 AM Dmitry Stogov wrote: > > > On 2/5/19 12:40 PM, Benjamin Eberlei wrote: > > > > > > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov > > wrote: > > > > > > > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > > > > On

Re: [PHP-DEV] phpenmod/phpdismod

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

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

wt., 5 lut 2019 o 10:24 Côme Chilliet napisał(a): > Hello, > > What is the usecase for this? > > The RFC does not explain what it would be useful for. > json_decode already provides an option for getting arrays instead of > objects. > > All in all the RFC does not provide enough information. As

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

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

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

Hi! > To me that is the purpose of voting, what you’re saying is like > complaining that in a democracy old people with experience has the > same voting power than young ones. To be clear, PHP user community is not a democracy, neither we want to be. In democracy, every person (marginal cases

Re: [PHP-DEV] [RFC] JIT

On 2/5/19 12:40 PM, Benjamin Eberlei wrote: > > > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov > wrote: > > > > On 2/5/19 1:48 AM, Benjamin Eberlei wrote: > > > > > > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei >

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

On Tue, 5 Feb 2019 at 12:22, Nikita Popov wrote: > Hi internals, > > I'd like to bring forward the following proposal for PHP 8, which will make > (zpp) parameter parsing failures always result in a TypeError (rather than > generating a warning+null, depending on circumstances): > >

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

On Tue, Feb 5, 2019 at 1:23 PM Girgias wrote: > On Tue, 5 Feb 2019 at 12:22, Nikita Popov wrote: > >> Hi internals, >> >> I'd like to bring forward the following proposal for PHP 8, which will >> make >> (zpp) parameter parsing failures always result in a TypeError (rather than >> generating a

Re: [PHP-DEV] phpenmod/phpdismod

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

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

On Tue, 5 Feb 2019 at 14:29, Nikita Popov wrote: > On Tue, Feb 5, 2019 at 1:23 PM Girgias wrote: > >> On Tue, 5 Feb 2019 at 12:22, Nikita Popov wrote: >> >>> [. . .] >>> >> >> I'm all for it but what is the scope of the RFC? >> Is it all core functions, bundled extension functions, or all

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

On Mo, 2019-02-04 at 15:32 +0200, Andrey Andreev wrote: > Hi, > > I could nitpick on most of the proposed plan, but I really only > wanted > to reply to this: > > > > > > > > > * A new home page, not a "news" page, but a page simply showing > > > the PHP Logo, a code example maybe and > > >

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

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

Re: [PHP-DEV] phpenmod/phpdismod

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

Re: [PHP-DEV] Disable PEAR by default

On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski wrote: > > > On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov wrote: > >> Hi internals, >> >> I would like to suggest that installation of PEAR is disabled by default >> in >> PHP 7.4. PR: https://github.com/php/php-src/pull/3781 > > > This thread went a

Re: [PHP-DEV] Disable PEAR by default

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

Re: [PHP-DEV] Re: RFC Weakrefs

Hi all, I have considered maps ... since it is possible to do in userland, I don't consider it super urgent, and even if you do, it doesn't become urgent until PHP 7.4 is much closer to release. So, we have almost a year; If this flies in, it's *highly* likely I'll follow it up ... but don't

Re: [PHP-DEV] RFC Weakrefs

Hi Joe, On 02.02.19 09:35, Joe Watkins wrote: Some time ago I brought this up for discussion, and last night was reminded of it's existence, and so this morning rebased and reworked the patch a little based on the feedback I got back then. Since it was long ago, and there's no particular rush,

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

On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov wrote: > Hi internals, > > When the silencing operator @ is used, the intention is generally to > silence expected warnings or notices. However, it currently also silences > fatal errors. As fatal errors also abort request execution, the result will

Re: [PHP-DEV] RFC Weakrefs

On Tue, Feb 5, 2019 at 4:11 PM Dennis Birkholz wrote: > Hi Joe, > > On 02.02.19 09:35, Joe Watkins wrote: > > Some time ago I brought this up for discussion, and last night was > reminded > > of it's existence, and so this morning rebased and reworked the patch a > > little based on the feedback

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

Le mardi 5 février 2019, 02:38:50 CET Stanislav Malyshev a écrit : > Hi! Hi! > Do you imagine Linus > asking a vote of all Linux users about how to implement a kernel driver > and implementing it only in a way that majority of Linux users approves? Not sure that would be so bad. At least until

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

Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit : > We'll have to agree to disagree on this one. I would say that the way > virtually every other major Open Source project serves as a fairly good > proof point for my position. In fact, even with the new eligible voting > criteria,

Re: [PHP-DEV] RFC Weakrefs

Hi Nikita, On 05.02.19 16:50, Nikita Popov wrote: Serialization for weak refs is a bit tricky, and I feel like supporting it could easily become a foot-gun. The fundamental problem is that for serialization to produce a meaningful value, the object referenced by a WeakReference must also be

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

On Mon, Feb 4, 2019 at 11:58 AM Craig Duncan wrote: > > Hi all, > > Following the discussion it's now time to vote on whether we make the > stdClass iterable or not. > https://wiki.php.net/rfc/iterable-stdclass > > Note that while there is an implementation available, the vote is only on >

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

Hi! > “Inactive”[1] is likely what you're looking for. Inactive implies it's not being worked on... But we certainly could move there at least ones that are "in discussion" for 2 years. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] RFC Weakrefs

On Tue, 5 Feb 2019 at 17:06, Dennis Birkholz wrote: > So I would really prefer the WeakReference class would just be > serializable with all the consequences you outlined. Maybe for PHP 8 we > will decide to require all classes to be serializable except classes > that implement the

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

On Tue, 5 Feb 2019 at 16:39, Levi Morrison wrote: > I just wanted to pipe in to suggest an alternative approach to > accomplish some of the same goals: an external PropertyIterator. > I believe Nikita suggested something similar, and while it would certainly be useful it doesn't accomplish the

[PHP-DEV] RFCs "under discussion"

Hi! Looking at our RFC page, we have over 50 RFCs under discussion. This is obviously not true - and can not be true, really, it's impossible to properly discuss 50+ RFCs at a time, and indeed most of these aren't being currently discussed. I propose to clean up that section and move RFCs for

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

On Tue, 5 Feb 2019 at 17:25, Craig Duncan wrote: > The *iterable* type accepts a plain array, but not an object that is used > to represent a plain array, that's surprising to me. > I think this notion of stdClass as "an object used to represent a plain array" is a peculiar one. The only

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

On Tue, Feb 5, 2019 at 6:02 PM Côme Chilliet wrote: > Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit : > > We'll have to agree to disagree on this one. I would say that the way > > virtually every other major Open Source project serves as a fairly good > > proof point for my

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

On 05.02.2019 at 18:40, Stanislav Malyshev wrote: > Looking at our RFC page, we have over 50 RFCs under discussion. This is > obviously not true - and can not be true, really, it's impossible to > properly discuss 50+ RFCs at a time, and indeed most of these aren't > being currently discussed. I

Re: [PHP-DEV] [RFC] JIT

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

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

On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov wrote: > On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov > wrote: > > > I'd like to move forward with this change. I think the overall reception > here has been positive, although in the discussion some other possibilities > that avoid/reduce the BC

Re: [PHP-DEV] [RFC] JIT

On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov wrote: > > PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%) > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%) > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000 > > -dopcache.jit=1201): 29.95s (92.7%)

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

On Tue, Feb 5, 2019 at 5:55 PM Zeev Suraski wrote: > On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov wrote: > >> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov >> wrote: >> >> >> I'd like to move forward with this change. I think the overall reception >> here has been positive, although in the

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

On Tue, 5 Feb 2019 at 17:40, Stanislav Malyshev wrote: > Hi! > > Looking at our RFC page, we have over 50 RFCs under discussion. This is > obviously not true - and can not be true, really, it's impossible to > properly discuss 50+ RFCs at a time, and indeed most of these aren't > being currently

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

Am Di., 5. Feb. 2019 um 18:40 Uhr schrieb Stanislav Malyshev : > > Hi! > > Looking at our RFC page, we have over 50 RFCs under discussion. This is > obviously not true - and can not be true, really, it's impossible to > properly discuss 50+ RFCs at a time, and indeed most of these aren't > being

Re: [PHP-DEV] RFC Weakrefs

On Tue, 5 Feb 2019 at 16:06, Dennis Birkholz wrote: > Maybe for PHP 8 we > will decide to require all classes to be serializable except classes > that implement the Unserializable interface or something... Or the magic > __isSerializable() method that can decide this at runtime for the actual >

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

> Is this your desired look you wanna propose? I may misunderstand and this is the original proposal : > https://twitter.com/azjezz/status/1091722433424285698 how ever people seem to lean more toward having releases and changlogs in the front-page. > - example code (with an option to run) i

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

I have two suggestions, assuming you proceed roughly as outlined in your original post. 1. Start with /community A new community website [4], it can be a place for people to ask questions and discuss php in general - no one uses IRC anymore. and use it to build and coordinate the dev team