PHP 7.2 forked

php.internals

Sara Golemon

9 years ago
That's it! Feature freeze is on. Please include branch PHP-7.2 in all merges from 7.1 and earlier. Please commit all 7.2 fixes to PHP-7.2 and merge to master which is now targetting 7.3 This is real. https://github.com/php/php-src/commit/5230541ef59e0637d5522293a7d099bf18ce6af3 -Sara

Jan Ehrhardt

9 years ago
Sara Golemon in php.internals (Tue, 18 Jul 2017 10:48:16 -0400):
>That's it! Feature freeze is on.
Congrats. Question, maybe for Anatol: what did change in the Windows Build environment? It was taking ages for 'Generating code', for each extension. Now it is as fast as building PHP 7.1.
-- Jan

Anatol Belski

9 years ago
Hi Jan,
> -----Original Message----- > From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl] > Sent: Tuesday, July 18, 2017 7:11 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Re: PHP 7.2 forked > > Sara Golemon in php.internals (Tue, 18 Jul 2017 10:48:16 -0400): > >That's it! Feature freeze is on. > > Congrats. Question, maybe for Anatol: what did change in the Windows Build > environment? It was taking ages for 'Generating code', for each extension. Now > it is as fast as building PHP 7.1. > --
There is no change in the build process, disregarding the requirement on the new SDK. The build efficiency usually depends on the power of the build host. What I can only guess, is that the removal of /LTCG for non PGO build could improve build speed on a less powerful machine. That option was added in master, but had to be removed due to compatibility issues. Regards Anatol

Jan Ehrhardt

9 years ago
Hi Anatol. Anatol Belski in php.internals (Wed, 19 Jul 2017 13:37:59 +0000):
>Hi Jan, > >> Congrats. Question, maybe for Anatol: what did change in the Windows Build >> environment? It was taking ages for 'Generating code', for each extension. Now >> it is as fast as building PHP 7.1. > >There is no change in the build process, disregarding the requirement on >the new SDK. The build efficiency usually depends on the power of the >build host. What I can only guess, is that the removal of /LTCG for non >PGO build could improve build speed on a less powerful machine. That >option was added in master, but had to be removed due to compatibility >issues.
The difference was very substantial on my Lenovo X220 with an Intel Core i7 2620M (2.7GHz). Of course, I was already using the new SDK.
-- Jan

Nikita Popov

9 years ago
On Tue, Jul 18, 2017 at 4:48 PM, Sara Golemon <pollita@php.net> wrote:
> That's it! Feature freeze is on. > > Please include branch PHP-7.2 in all merges from 7.1 and earlier. > Please commit all 7.2 fixes to PHP-7.2 and merge to master which is > now targetting 7.3 > > This is real. https://github.com/php/php-src/commit/ > 5230541ef59e0637d5522293a7d099bf18ce6af3 > > -Sara >
What's out current state regarding ABI? I've recently done some work on making mbstring slightly less abysmally slow, but landed the changes on master only, because this included ABI breaks in mbfl/mbstring APIs and globals. Is this something I can land in PHP-7.2, or is it closed to extension ABI changes? Nikita

Kalle Sommer Nielsen

9 years ago
2017-07-22 18:48 GMT+02:00 Nikita Popov <nikita.ppv@gmail.com>:
> What's out current state regarding ABI? I've recently done some work on > making mbstring slightly less abysmally slow, but landed the changes on > master only, because this included ABI breaks in mbfl/mbstring APIs and > globals. Is this something I can land in PHP-7.2, or is it closed to > extension ABI changes?
afair ABI can be broken until a branch/release hits RC, after that its on case by case basis
-- regards, Kalle Sommer Nielsen kalle@php.net

Anatol Belski

9 years ago
Hi Nikita,
> -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: Saturday, July 22, 2017 6:48 PM > To: Sara Golemon <pollita@php.net> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PHP 7.2 forked > > On Tue, Jul 18, 2017 at 4:48 PM, Sara Golemon <pollita@php.net> wrote: > > > That's it! Feature freeze is on. > > > > Please include branch PHP-7.2 in all merges from 7.1 and earlier. > > Please commit all 7.2 fixes to PHP-7.2 and merge to master which is > > now targetting 7.3 > > > > This is real. https://github.com/php/php-src/commit/ > > 5230541ef59e0637d5522293a7d099bf18ce6af3 > > > > -Sara > > > > What's out current state regarding ABI? I've recently done some work on making > mbstring slightly less abysmally slow, but landed the changes on master only, > because this included ABI breaks in mbfl/mbstring APIs and globals. Is this > something I can land in PHP-7.2, or is it closed to extension ABI changes? >
I was checking the patch so far, frankly I'm not sure how stable it is yet. But if RMs accept it, I think quite some stress test should be done. Anyway, as libmbfl doesn't seem to be active for long, patching it for better compatibility seems a right step. Regards Anatol

Sara Golemon

9 years ago
On Sat, Jul 22, 2017 at 12:48 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> What's out current state regarding ABI? I've recently done some work on > making mbstring slightly less abysmally slow, but landed the changes on > master only, because this included ABI breaks in mbfl/mbstring APIs and > globals. Is this something I can land in PHP-7.2, or is it closed to > extension ABI changes? >
During beta I'm willing to tolerate some ABI breaks for high-value things, but while mbstring performance is inarguably a good thing, stability is an even better thing. Anatol mentioned concern about stability, ergo I'm inclined to defer these improvements till 7.3. -Sara

Nikita Popov

9 years ago
On Sun, Jul 23, 2017 at 3:55 AM, Sara Golemon <pollita@php.net> wrote:
> On Sat, Jul 22, 2017 at 12:48 PM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > > What's out current state regarding ABI? I've recently done some work on > > making mbstring slightly less abysmally slow, but landed the changes on > > master only, because this included ABI breaks in mbfl/mbstring APIs and > > globals. Is this something I can land in PHP-7.2, or is it closed to > > extension ABI changes? > > > During beta I'm willing to tolerate some ABI breaks for high-value > things, but while mbstring performance is inarguably a good thing, > stability is an even better thing. Anatol mentioned concern about > stability, ergo I'm inclined to defer these improvements till 7.3. > > -Sara >
What Anatol is probably referring to here is that next to the performance improvements, the mbstring extension has also been migrated to use size_t instead of int lengths. This is something we originally overlooked during the size_t port in PHP 7. This is a major change and its easy to overlook something, so the concern for stability is well justified. Conversely, this does also fix a range of length overflow related bugs (I have manually verified this on a sample of related bug reports). Nikita

Anatol Belski

9 years ago
Hi Nikita,
> -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: Sunday, July 23, 2017 12:52 PM > To: Sara Golemon <pollita@php.net> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PHP 7.2 forked > > On Sun, Jul 23, 2017 at 3:55 AM, Sara Golemon <pollita@php.net> wrote: > > > On Sat, Jul 22, 2017 at 12:48 PM, Nikita Popov <nikita.ppv@gmail.com> > > wrote: > > > What's out current state regarding ABI? I've recently done some work > > > on making mbstring slightly less abysmally slow, but landed the > > > changes on master only, because this included ABI breaks in > > > mbfl/mbstring APIs and globals. Is this something I can land in > > > PHP-7.2, or is it closed to extension ABI changes? > > > > > During beta I'm willing to tolerate some ABI breaks for high-value > > things, but while mbstring performance is inarguably a good thing, > > stability is an even better thing. Anatol mentioned concern about > > stability, ergo I'm inclined to defer these improvements till 7.3. > > > > -Sara > > > > What Anatol is probably referring to here is that next to the performance > improvements, the mbstring extension has also been migrated to use size_t > instead of int lengths. This is something we originally overlooked during the > size_t port in PHP 7. This is a major change and its easy to overlook something, > so the concern for stability is well justified. Conversely, this does also fix a range > of length overflow related bugs (I have manually verified this on a sample of > related bug reports). >
Ok, so seems I mistook the intention then and you were referring to these only (or at least) http://git.php.net/?p=php-src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85 http://git.php.net/?p=php-src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850 http://git.php.net/?p=php-src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873 http://git.php.net/?p=php-src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134 http://git.php.net/?p=php-src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef That's indeed a different matter. Some indeed contain minimal API breach. In some case it could be reduced by keeping the old symbol unchanged while introducing a new one. For example `php_unicode_is_prop` could be kept, but the other new one could be `php_unicode_is_prop_va`. Leaving the size_t patches for master only, the breach is minimal and could be even yet more minimized. Sara, if this sounds manageable to you, perhaps you could still consider to evaluate the subset only, perhaps on a dedicated patch. Regards Anatol

Sara Golemon

9 years ago
On Sun, Jul 23, 2017 at 7:58 AM, Anatol Belski <weltling@outlook.de> wrote:
> Ok, so seems I mistook the intention then and you were referring to these only (or at least) > > http://git.php.net/?p=php-src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85 > http://git.php.net/?p=php-src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850 > http://git.php.net/?p=php-src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873 > http://git.php.net/?p=php-src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134 > http://git.php.net/?p=php-src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef >
Yeah, go ahead and put those on 7.2 -Sara

Nikita Popov

9 years ago
On Sun, Jul 23, 2017 at 9:19 PM, Sara Golemon <pollita@php.net> wrote:
> On Sun, Jul 23, 2017 at 7:58 AM, Anatol Belski <weltling@outlook.de> > wrote: > > Ok, so seems I mistook the intention then and you were referring to > these only (or at least) > > > > http://git.php.net/?p=php-src.git;a=commitdiff;h= > dead4f0b1b9a555bbea970f5399c01142414db85 > > http://git.php.net/?p=php-src.git;a=commitdiff;h= > 4cf22cbb2d3b777cceb0087cdfd2a571aaf76850 > > http://git.php.net/?p=php-src.git;a=commitdiff;h= > 4128746b949355f588143ef18ad98fdfda089873 > > http://git.php.net/?p=php-src.git;a=commitdiff;h= > 9c73be898d4e5aa2e64b21da14797ec9ad202134 > > http://git.php.net/?p=php-src.git;a=commitdiff;h= > 79c26d597fd8245c30ee74faf05b8d6f9ece3fef > > > Yeah, go ahead and put those on 7.2 > > -Sara >
I've decided to leave all the changes to master only. At this point there are so many entangled changes that I don't think a partial backport is worthwhile. Some of the more important changes happened after the size_t and no_encoding ports, so applying them to 7.2 without the other refactoring would take additional work. Nikita

Anatol Belski

9 years ago
> -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: Wednesday, July 26, 2017 2:48 PM > To: Sara Golemon <pollita@php.net> > Cc: Anatol Belski <weltling@outlook.de>; PHP internals > <internals@lists.php.net> > Subject: Re: [PHP-DEV] PHP 7.2 forked > > On Sun, Jul 23, 2017 at 9:19 PM, Sara Golemon <pollita@php.net > <mailto:pollita@php.net> > wrote: > > > On Sun, Jul 23, 2017 at 7:58 AM, Anatol Belski <weltling@outlook.de > <mailto:weltling@outlook.de> > wrote: > > Ok, so seems I mistook the intention then and you were referring to > these only (or at least) > > > > http://git.php.net/?p=php- > src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85 > <http://git.php.net/?p=php- > src.git;a=commitdiff;h=dead4f0b1b9a555bbea970f5399c01142414db85> > > http://git.php.net/?p=php- > src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850 > <http://git.php.net/?p=php- > src.git;a=commitdiff;h=4cf22cbb2d3b777cceb0087cdfd2a571aaf76850> > > http://git.php.net/?p=php- > src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873 > <http://git.php.net/?p=php- > src.git;a=commitdiff;h=4128746b949355f588143ef18ad98fdfda089873> > > http://git.php.net/?p=php- > src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134 > <http://git.php.net/?p=php- > src.git;a=commitdiff;h=9c73be898d4e5aa2e64b21da14797ec9ad202134> > > http://git.php.net/?p=php- > src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef > <http://git.php.net/?p=php- > src.git;a=commitdiff;h=79c26d597fd8245c30ee74faf05b8d6f9ece3fef> > > > Yeah, go ahead and put those on 7.2 > > -Sara > > > > I've decided to leave all the changes to master only. At this point there are so > many entangled changes that I don't think a partial backport is worthwhile. > Some of the more important changes happened after the size_t and > no_encoding ports, so applying them to 7.2 without the other refactoring would > take additional work. >
ACK, I'll put #74929 into the master news and close it. Regards Anatol