Re: [PHP-DEV] ZEND_ACC_* flags
On Wed, Jul 25, 2018 at 11:01 AM, Dmitry Stogov wrote: > > I tried to fix ZEND_ACC_* flags mess. > > https://gist.github.com/dstogov/3b6ae377c17524b219670960cf98f8c1 > > > The patch specifies flags meaning, and reorder them according to meaning and > frequency of usage (this allows generation of shorter instructions on x86). > Unfortunately, the patch breaks few reflection based tests that relay on > binary modifiers values. > Documentation part: LOVE LOVE LOVE Renumbering part: Eh, could save that for 8.0, but I won't complain about it in 7.4. Whichever version it lands in, please make a bump to ZEND_MODULE_API_NO part of the commit, and a comment in UPGRADING.INTERNALS as well. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: ZEND_ACC_* flags
OK. I'll keep this for next PHP version. There is no any performance improvement (just a bit smaller code). The patch clarifies the meaning of all the flags, what entities use them, and points what some of them may be eliminated completely. Thanks. Dmitry. From: Stanislav Malyshev Sent: Wednesday, July 25, 2018 9:35:11 PM To: Dmitry Stogov; Christoph M. Becker; PHP internals list Cc: Nikita Popov Subject: Re: ZEND_ACC_* flags Hi! > I tried to fix ZEND_ACC_* flags mess. > > > https://gist.github.com/dstogov/3b6ae377c17524b219670960cf98f8c1 > > > The patch specifies flags meaning, and reorder them according to meaning > and frequency of usage (this allows generation of shorter instructions > on x86). > > Unfortunately, the patch breaks few reflection based tests that relay on > binary modifiers values. I am not sure I understand what the effect is here - does it allow any measurable improvement? If not, I'd wait until the after the branch. But I could change my mind if there's real performance gain... The test part, however, which replaces bits with constants, I think is good anytime, I don't think we should have been using bit values anyway. -- Stas Malyshev smalys...@gmail.com
[PHP-DEV] Re: ZEND_ACC_* flags
Hi! > I tried to fix ZEND_ACC_* flags mess. > > > https://gist.github.com/dstogov/3b6ae377c17524b219670960cf98f8c1 > > > The patch specifies flags meaning, and reorder them according to meaning > and frequency of usage (this allows generation of shorter instructions > on x86). > > Unfortunately, the patch breaks few reflection based tests that relay on > binary modifiers values. I am not sure I understand what the effect is here - does it allow any measurable improvement? If not, I'd wait until the after the branch. But I could change my mind if there's real performance gain... The test part, however, which replaces bits with constants, I think is good anytime, I don't think we should have been using bit values anyway. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_ACC_* flags
This can potentially break some cached flags somewhere, and is a BC break: any rationale behind the change? On Wed, 25 Jul 2018, 17:01 Dmitry Stogov, wrote: > Hi, > > > I tried to fix ZEND_ACC_* flags mess. > > > https://gist.github.com/dstogov/3b6ae377c17524b219670960cf98f8c1 > > > The patch specifies flags meaning, and reorder them according to meaning > and frequency of usage (this allows generation of shorter instructions on > x86). > > Unfortunately, the patch breaks few reflection based tests that relay on > binary modifiers values. > > > Do you think, it it's OK to commit thin into 7.3 or better to wait for > branching? > > > Thanks. Dmitry. >
[PHP-DEV] ZEND_ACC_* flags
Hi, I tried to fix ZEND_ACC_* flags mess. https://gist.github.com/dstogov/3b6ae377c17524b219670960cf98f8c1 The patch specifies flags meaning, and reorder them according to meaning and frequency of usage (this allows generation of shorter instructions on x86). Unfortunately, the patch breaks few reflection based tests that relay on binary modifiers values. Do you think, it it's OK to commit thin into 7.3 or better to wait for branching? Thanks. Dmitry.
Re: [PHP-DEV] Copyright/License issue
Hi! On 25.07.2018 at 09:17, Jakub Zelenka wrote: > On Wed, 25 Jul 2018, 00:15 Christoph M. Becker, wrote: > >> I've just stumbled upon sapi/fpm/fpm/fpm_status.c[1], which claims >> copyright by Jerome Loyet and doesn't state any license. It seems to me >> that we must not ship/modify this file > > Why do you think that and how is it diffiren to all other fpm files? FPM is > BSD licensed (see the LICENSE file) so I think we can modify any file as we > want and it's been always like this - we have already modified it anyway. > The copyright in the files are for the specific year(s) so I think we > should actually add line below with PHP Group copyright or whatever for the > years when it was modified but not really sure what's the right way to deal > with that... Thanks! I should have checked this more carefully. The LICENSE file in the folder above may well be sufficient. I would appreciate, though, if there was a short license hint/indicator in each file (at least if there is a copyright notice), and indeed it appears sensible to add copyright lines to indicate that individual files have been modified. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Copyright/License issue
Hi On Wed, 25 Jul 2018, 00:15 Christoph M. Becker, wrote: > Hi! > > I've just stumbled upon sapi/fpm/fpm/fpm_status.c[1], which claims > copyright by Jerome Loyet and doesn't state any license. It seems to me > that we must not ship/modify this file > Why do you think that and how is it diffiren to all other fpm files? FPM is BSD licensed (see the LICENSE file) so I think we can modify any file as we want and it's been always like this - we have already modified it anyway. The copyright in the files are for the specific year(s) so I think we should actually add line below with PHP Group copyright or whatever for the years when it was modified but not really sure what's the right way to deal with that... Cheers Jakub >
