Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Ahhh okay that explains where this change is coming from. Thanks a lot, Dan!

I wonder if this side effect ("all dependencies are iterated also
during "make install") is intentional.

Maybe Niki can chime in on GitHub; I'll ping him there, as well as the
original author.

Thanks a lot!

David

P.S. regarding your earlier comment on the '-include' directive - that
allows the actual file you're specifying there to be missing; not any
file names listed inside it - the purpose is to optionally let
generic/templated Makefiles specify a file that lists additional
includes, but making that file itself optional.

On Thu, Dec 9, 2021 at 8:41 PM Dan Ackroyd  wrote:
>
> On Thu, 9 Dec 2021 at 19:28, Dan Ackroyd  wrote:
> > >  Is this intentional? If so, could someone explain the purpose of the 
> > > change?
> >
> > Probably to make the build process less flaky, by explicitly checking
> > dependencies, so that there are fewer instances of "stuffs not
> > working.I guess I'll do a make clean and see if that helps".
> >
>
> And of course I find the commit just after sending previous email:
>
> commit - 
> https://github.com/php/php-src/commit/c4d508c2bc09860bfa15b7f520e0ba68425acfc1
> reasoning - https://github.com/php/php-src/pull/6693
>
> cheers
> Dan
> Ack

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

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Thanks for your response! I'm not removing PHP before *compiling*, I
am removing it before *installing*:

1) download/extract PHP (as a build dependency) to $PREFIX
2) phpize
3) ./configure --prefix=$PREFIX
4) make
5) remove PHP from $PREFIX
6) make install

The purpose is to have a clean $PREFIX directory that, in its
entirety, can be compressed into an archive for distribution of only
that extension's files.

Does that make sense?

On Thu, Dec 9, 2021 at 8:28 PM Dan Ackroyd  wrote:
>
> On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals
>  wrote:
> >
> > That doesn't work with PHP 8.1 anymore - the Makefile generated by
> > phpize now contains an include directive at the top level (near the
> > bottom), e.g.:
> >
> > -include src/php_raphf_api.dep
>
> The file src/php_raphf_api.dep is created when the source code is
> compiled. It creates a list of which files were used in the
> compilation of a C file. In this case src/php_raphf_api.c
>
> The '-include' directive apparently allows for a file to be listed,
> but not error when it doesn't exist, apparently:
> https://www.gnu.org/software/make/manual/html_node/Features.html so on
> a fresh cleaned build, it shouldn't make any difference.
>
> > Which lists not only the extension's headers, but also all of PHP's
> > (in include/main, include/Zend, and so forth):
>
> Yes. Those are the files that need to be present to compile that
> source code file. It's used to check to see if a C file should be
> recompiled, as one of it's dependencies has changed. The dep file is
> also deleted when doing make clean.
>
> It doesn't appear to me that the change to the phpize and the dep file
> is affecting other peopleI think the problem you're seeing is
> something unique to your build process. In particular:
>
> 1. Are you doing a make clean, or is there a chance of left over files
> from a previous build?
>
> 2. Why are you (as far as I understand) deleting the PHP files in `5)
> rm -rf $installdir`, before compiling the extension? The command `make
> install` does a check on whether anything needs recompiling.and I
> believe it's failing because the files it's trying to check no longer
> exist.
>
> >  Is this intentional? If so, could someone explain the purpose of the 
> > change?
>
> Probably to make the build process less flaky, by explicitly checking
> dependencies, so that there are fewer instances of "stuffs not
> working.I guess I'll do a make clean and see if that helps".
>
> cheers
> Dan
> Ack

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

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

See my previous messages; there's step by step output where I trigger
it with your extension by renaming the directory containing the PHP
it's built against (this obviously requires you have a PHP that's
built with --prefix=/usr/local/myphpbuild or whatever).

I suppose the solution for now is to use 'make
INSTALL_ROOT=/tmp/mypackagedir install', but that's a PHP specific
thing; other software, like Nginx for example, uses the more
"standard" DESTDIR variable as recommended by
https://www.gnu.org/prep/standards/html_node/DESTDIR.html for staged
installs.

That's why I am asking here for the reason this change was made. If
it's unintentional, then it should be fixable; if it's on purpose,
then maybe migrating PHP's Makefiles to also use DESTDIR would be
useful in order to allow generic build tooling to have fewer special
cases for PHP.

David


On Thu, Dec 9, 2021 at 6:14 PM Glash Gnome  wrote:
>
> Right.
> > configure && make && make install
> works.
>
> For my personal information : Now which command should I use to get the error 
> ?
>
>
> Le jeu. 9 déc. 2021 à 17:34, David Zuelke  a écrit :
>>
>> Of course a 'make && make install' works. That is *not* what's broken
>> since 8.1, and not what I'm talking about.
>>
>>
>> On Thu, Dec 9, 2021 at 4:53 PM Glash Gnome  wrote:
>> >
>> > Thanks a lot.
>> > I use PHP 8.2.0-dev (cli) (built: Dec  8 2021 23:53:19) (NTS)
>> > And I can't reproduce the error with my build procedure.
>> > But, if I use "make -d install' insteadof "make && make install' I get 
>> > errors.
>> >
>> > Can you confirm it ?
>> >
>> >
>> >
>> >
>> >
>> > Le jeu. 9 déc. 2021 à 03:19, David Zuelke  a écrit 
>> > :
>> >>
>> >> Yes, of course; it happens with any extension, because the Makefile
>> >> generated by 8.1's 'phpize' now lists those header dependencies even
>> >> for 'make install'.
>> >>
>> >> Like I described, you can reproduce this by 'make'ing the extension,
>> >> then moving the PHP you used to build the extension, then running
>> >> 'make install' (sample with your ext, on my build environment for
>> >> Heroku's PHP support):
>> >>
>> >> root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
>> >> root@8f6813d6dc88:/app# which php
>> >> /app/.heroku/php/bin/php
>> >> root@8f6813d6dc88:/app# php -v
>> >> PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
>> >> Copyright (c) The PHP Group
>> >> Zend Engine v4.1.0, Copyright (c) Zend Technologies
>> >> with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
>> >>
>> >> root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
>> >> root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
>> >> https://github.com/gtkphp/php-ext-cairo-src
>> >> Cloning into 'php-ext-cairo-src'...
>> >> …
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
>> >> origin/PHP-8.0
>> >> Note: checking out 'origin/PHP-8.0'.
>> >>
>> >> You are in 'detached HEAD' state. You can look around, make experimental
>> >> …
>> >>
>> >> HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
>> >> Configuring for:
>> >> PHP Api Version: 20210902
>> >> Zend Module Api No:  20210902
>> >> Zend Extension Api No:   420210902
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
>> >> --prefix=/app/.heroku/php
>> >> …
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
>> >> …
>> >> Build complete.
>> >> Don't forget to run 'make test'.
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
>> >> /app/.heroku/php{,_}
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
>> >> make: *** No rule to make target
>&

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Of course a 'make && make install' works. That is *not* what's broken
since 8.1, and not what I'm talking about.


On Thu, Dec 9, 2021 at 4:53 PM Glash Gnome  wrote:
>
> Thanks a lot.
> I use PHP 8.2.0-dev (cli) (built: Dec  8 2021 23:53:19) (NTS)
> And I can't reproduce the error with my build procedure.
> But, if I use "make -d install' insteadof "make && make install' I get errors.
>
> Can you confirm it ?
>
>
>
>
>
> Le jeu. 9 déc. 2021 à 03:19, David Zuelke  a écrit :
>>
>> Yes, of course; it happens with any extension, because the Makefile
>> generated by 8.1's 'phpize' now lists those header dependencies even
>> for 'make install'.
>>
>> Like I described, you can reproduce this by 'make'ing the extension,
>> then moving the PHP you used to build the extension, then running
>> 'make install' (sample with your ext, on my build environment for
>> Heroku's PHP support):
>>
>> root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
>> root@8f6813d6dc88:/app# which php
>> /app/.heroku/php/bin/php
>> root@8f6813d6dc88:/app# php -v
>> PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
>> Copyright (c) The PHP Group
>> Zend Engine v4.1.0, Copyright (c) Zend Technologies
>> with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
>>
>> root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
>> root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
>> root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
>> https://github.com/gtkphp/php-ext-cairo-src
>> Cloning into 'php-ext-cairo-src'...
>> …
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
>> origin/PHP-8.0
>> Note: checking out 'origin/PHP-8.0'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> …
>>
>> HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
>> Configuring for:
>> PHP Api Version: 20210902
>> Zend Module Api No:  20210902
>> Zend Extension Api No:   420210902
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
>> --prefix=/app/.heroku/php
>> …
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
>> …
>> Build complete.
>> Don't forget to run 'make test'.
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
>> /app/.heroku/php{,_}
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
>> make: *** No rule to make target
>> '/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
>> Stop.
>>
>>
>> On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome  wrote:
>> >
>> > Thanks, I'll check it out.
>> >
>> > I'm confused. Can you tell me if you have this problem with this extension 
>> > (PHP8 / 7/5>):
>> > https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
>> >
>> > At the moment I need to check some dependency to try your extension.
>> > I'll keep you informed.
>> >
>> > Best Regards
>> >
>> > Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a écrit 
>> > :
>> >>
>> >> That's... sort of... irrelevant for this question; the problem appears
>> >> before that step. You could make a tarball of the built extension,
>> >> create a .deb archive, whatever; the point is that it should be
>> >> installable standalone (think e.g. 'apt-get install php81-imagick').
>> >>
>> >>
>> >>
>> >> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > Can you tell me what the program is in step 7)
>> >> >
>> >> > > package up
>> >> >
>> >> > Thanks you,
>> >> >
>> >> >
>> >> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals 
>> >> >  a écrit :
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> When building shared extensions for PHP for the purpose of packaging
>> >> >> and distributing the builds, the build environment obviously needs 

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Yes, of course; it happens with any extension, because the Makefile
generated by 8.1's 'phpize' now lists those header dependencies even
for 'make install'.

Like I described, you can reproduce this by 'make'ing the extension,
then moving the PHP you used to build the extension, then running
'make install' (sample with your ext, on my build environment for
Heroku's PHP support):

root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
root@8f6813d6dc88:/app# which php
/app/.heroku/php/bin/php
root@8f6813d6dc88:/app# php -v
PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.0, Copyright (c) Zend Technologies
with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies

root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
https://github.com/gtkphp/php-ext-cairo-src
Cloning into 'php-ext-cairo-src'...
…

root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
origin/PHP-8.0
Note: checking out 'origin/PHP-8.0'.

You are in 'detached HEAD' state. You can look around, make experimental
…

HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
Configuring for:
PHP Api Version: 20210902
Zend Module Api No:  20210902
Zend Extension Api No:   420210902

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
--prefix=/app/.heroku/php
…

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
…
Build complete.
Don't forget to run 'make test'.

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
/app/.heroku/php{,_}

root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
make: *** No rule to make target
'/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
Stop.


On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome  wrote:
>
> Thanks, I'll check it out.
>
> I'm confused. Can you tell me if you have this problem with this extension 
> (PHP8 / 7/5>):
> https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
>
> At the moment I need to check some dependency to try your extension.
> I'll keep you informed.
>
> Best Regards
>
> Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a écrit :
>>
>> That's... sort of... irrelevant for this question; the problem appears
>> before that step. You could make a tarball of the built extension,
>> create a .deb archive, whatever; the point is that it should be
>> installable standalone (think e.g. 'apt-get install php81-imagick').
>>
>>
>>
>> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
>> >
>> > Hello,
>> >
>> > Can you tell me what the program is in step 7)
>> >
>> > > package up
>> >
>> > Thanks you,
>> >
>> >
>> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals 
>> >  a écrit :
>> >>
>> >> Hi all,
>> >>
>> >> When building shared extensions for PHP for the purpose of packaging
>> >> and distributing the builds, the build environment obviously needs PHP
>> >> installed in the destination directory structure (for headers, phpize,
>> >> and so forth).
>> >>
>> >> But the resulting archive of the built extension should only contain
>> >> the shared object, and possibly the headers.
>> >>
>> >> A common pattern to do achieve is:
>> >>
>> >> 1) download/extract PHP to $installdir
>> >> 2) download/extract extension to $builddir
>> >> 3) phpize in $builddir
>> >> 4) make in $builddir
>> >> 5) rm -rf $installdir
>> >> 6) make install
>> >> 7) package up $installdir
>> >>
>> >> Step 6 installs the extension into $installdir - you end up with
>> >> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
>> >>
>> >> That doesn't work with PHP 8.1 anymore - the Makefile generated by
>> >> phpize now contains an include directive at the top level (near the
>> >> bottom), e.g.:
>> >>
>> >> -include src/php_raphf_api.dep
>> >>
>> >> Which lists not only the extension's headers, but also all of PHP's
>> >> (in include/main, include/Zend, and so forth):
>> >>
>> >> src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
>> >>  config

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

That's... sort of... irrelevant for this question; the problem appears
before that step. You could make a tarball of the built extension,
create a .deb archive, whatever; the point is that it should be
installable standalone (think e.g. 'apt-get install php81-imagick').



On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
>
> Hello,
>
> Can you tell me what the program is in step 7)
>
> > package up
>
> Thanks you,
>
>
> Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals 
>  a écrit :
>>
>> Hi all,
>>
>> When building shared extensions for PHP for the purpose of packaging
>> and distributing the builds, the build environment obviously needs PHP
>> installed in the destination directory structure (for headers, phpize,
>> and so forth).
>>
>> But the resulting archive of the built extension should only contain
>> the shared object, and possibly the headers.
>>
>> A common pattern to do achieve is:
>>
>> 1) download/extract PHP to $installdir
>> 2) download/extract extension to $builddir
>> 3) phpize in $builddir
>> 4) make in $builddir
>> 5) rm -rf $installdir
>> 6) make install
>> 7) package up $installdir
>>
>> Step 6 installs the extension into $installdir - you end up with
>> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
>>
>> That doesn't work with PHP 8.1 anymore - the Makefile generated by
>> phpize now contains an include directive at the top level (near the
>> bottom), e.g.:
>>
>> -include src/php_raphf_api.dep
>>
>> Which lists not only the extension's headers, but also all of PHP's
>> (in include/main, include/Zend, and so forth):
>>
>> src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
>>  config.h /app/.heroku/php/include/php/main/php.h \
>>  /app/.heroku/php/include/php/main/php_version.h \
>>  /app/.heroku/php/include/php/Zend/zend_stream.h \
>>  /app/.heroku/php/include/php/main/streams/php_stream_context.h \
>> … (many more from main/ and Zend/ here)
>>  /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
>>  php_raphf_api.h php_raphf.h
>>
>> This results in the 'make install' failing if, like in our step 5
>> above, PHP itself has been (re-)moved since the 'make' (output that
>> follows is from a 'make -d install'):
>>
>>   Considering target file 'src/php_raphf_api.lo'.
>> …
>> Considering target file '/app/.heroku/php/include/php/main/php.h'.
>>  File '/app/.heroku/php/include/php/main/php.h' does not exist.
>>  Looking for an implicit rule for
>> '/app/.heroku/php/include/php/main/php.h'.
>>  Trying pattern rule with stem 'php'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/php.h,v'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/RCS/php.h,v'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/RCS/php.h'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/s.php.h'.
>>  Trying pattern rule with stem 'php.h'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main/SCCS/s.php.h'.
>>  Trying pattern rule with stem 'php'.
>>  Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>>  Looking for a rule with intermediate file
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
>>   Avoiding implicit rule recursion.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h,v'.
>>   Trying pattern rule with stem 'php.h'.
>>   Trying implicit prerequisite
>> '/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h,v'.
>>   Trying pattern rule with stem '

[PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Hi all,

When building shared extensions for PHP for the purpose of packaging
and distributing the builds, the build environment obviously needs PHP
installed in the destination directory structure (for headers, phpize,
and so forth).

But the resulting archive of the built extension should only contain
the shared object, and possibly the headers.

A common pattern to do achieve is:

1) download/extract PHP to $installdir
2) download/extract extension to $builddir
3) phpize in $builddir
4) make in $builddir
5) rm -rf $installdir
6) make install
7) package up $installdir

Step 6 installs the extension into $installdir - you end up with
/foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so

That doesn't work with PHP 8.1 anymore - the Makefile generated by
phpize now contains an include directive at the top level (near the
bottom), e.g.:

-include src/php_raphf_api.dep

Which lists not only the extension's headers, but also all of PHP's
(in include/main, include/Zend, and so forth):

src/php_raphf_api.lo: /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
 config.h /app/.heroku/php/include/php/main/php.h \
 /app/.heroku/php/include/php/main/php_version.h \
 /app/.heroku/php/include/php/Zend/zend_stream.h \
 /app/.heroku/php/include/php/main/streams/php_stream_context.h \
… (many more from main/ and Zend/ here)
 /app/.heroku/php/include/php/ext/standard/info.h php_raphf.h \
 php_raphf_api.h php_raphf.h

This results in the 'make install' failing if, like in our step 5
above, PHP itself has been (re-)moved since the 'make' (output that
follows is from a 'make -d install'):

  Considering target file 'src/php_raphf_api.lo'.
…
Considering target file '/app/.heroku/php/include/php/main/php.h'.
 File '/app/.heroku/php/include/php/main/php.h' does not exist.
 Looking for an implicit rule for
'/app/.heroku/php/include/php/main/php.h'.
 Trying pattern rule with stem 'php'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/php.h,v'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/RCS/php.h,v'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/RCS/php.h'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/s.php.h'.
 Trying pattern rule with stem 'php.h'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main/SCCS/s.php.h'.
 Trying pattern rule with stem 'php'.
 Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
 Looking for a rule with intermediate file
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h'.
  Avoiding implicit rule recursion.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/php.h,v'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h,v'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/RCS/php.h'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/s.php.h'.
  Trying pattern rule with stem 'php.h'.
  Trying implicit prerequisite
'/app/.heroku/php/include/php/main//tmp/bob-1830jl/raphf-2.0.1/src/SCCS/s.php.h'.
 No implicit rule found for '/app/.heroku/php/include/php/main/php.h'.
 Finished prerequisites of target file
'/app/.heroku/php/include/php/main/php.h'.
Must remake target '/app/.heroku/php/include/php/main/php.h'.
make: *** No rule to make target
'/app/.heroku/php/include/php/main/php.h', needed by
'src/php_raphf_api.lo'.  Stop.

Building extensions for 8.0 or lower doesn't generate such a
`src/php_EXTNAME_api.dep` file.

Is this intentional? If so, could someone explain the purpose of the
change? I couldn't find anything insightful when browsing the Git
logs.

The workaround is to

make INSTALL_ROOT=$SOMETEMPDIR install

and then move things into place for packaging, but I was still
wondering why this change was made in the first place.

Thanks and greetings,

David

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

Re: [PHP-DEV] PHP 7.4.7 Released!

[David Zuelke via internals]

The 7.4.7 release post on php.net links to
http://www.php.net/ChangeLog-7.php#7.4.6 for the changelog.

On Thu, Jun 11, 2020 at 4:16 PM Derick Rethans  wrote:
>
> The PHP development team announces the immediate availability of PHP
> 7.4.7. This is a security bug fix release.
>
> All PHP 7.4 users are encouraged to upgrade to this version.
>
> For source downloads of PHP 7.4.7 please visit our downloads page.
> Windows binaries can be found on the PHP for Windows site. The list of
> changes is recorded in the ChangeLog.
>
> A migration guide is available in the PHP Manual. Please consult it for the
> detailed list of new features and backward incompatible changes.
>
> Release Announcement: 
> Downloads:
> Windows downloads:
> Changelog:
> Migration guide:  
>
> Many thanks to all the contributors and supporters!
>
> Derick Rethans
>
> P.S. Below is the verification information for the downloads, which is
> also available on
> .
>
> php-7.4.7.tar.gz
> SHA256 hash: a554a510190e726ebe7157fb00b4aceabdb50c679430510a3b93cbf5d7546e44
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl7fa14ACgkQkQ3rRvU+
> oxI1/Q/8CWuODaD1b83dJo2k5Yw4sbbKrBGPKPdVvvFXV9Aoe5tiUU0EPAlivMDL
> MY0Nd7KLslU+umlWpfvVxGdXR0lr5Z5P3bJ81S7ynmFDJShL8jzr3MTNifSEdoQ5
> nTYmMRnhpZyNkCBMowpm/imFahATUlF4yl3ofZKbQj5dcoPmFMCjH0i/kd2iJeDA
> LWWBd2IuaYJyy6YsL6x4DAsNuTPFeIStPhoHH2BKkAIqTt4T5uiHtkDZKm9o2EUM
> 2gqWqeq0kX1VZzRTpLMDEHVZ50mgnnZCyKs/vZzIFW1KDFlHuUb+SkWyNWEDprtt
> Y/TRvK4uAjPo9wJWC4d1+zt788oYpitvf1M4S9E915WA3kwauZGGst3R1JV19WMm
> ZjAwlAcrbit0oxih4JkmiWh+wLcci/nLOTwZvueuL07fQWnXab4OvR3prlMxT3oX
> k9zaV75xEcE3CgszJM99xTYpgjAAH62mEmF+FGAtUpb9Kzj1/dcqf+LbzXQJSGh/
> W85bD84fjJ8nj2fhRoptNYETFQXgNMR48FL9EPhp2okNcAX7PM/6P8OxvOS/rudF
> lGzjL0Ktz+BfrfAQZlCitd3EKow9E1583JGTDqSPChmQoxS+lpoPRz2r6DSHHL9o
> IwRyEovI7OJKpL1/7WLIDGg99rDcjspLkLCj+/lBlh7yZSoEFpA=
> =wg2w
> -END PGP SIGNATURE-
>
> php-7.4.7.tar.bz2
> SHA256 hash: 800e0d01f359c8ec41540925c0d4a24c34d5f21ef6addd6d82ff4a52be23d87a
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl7fa2MACgkQkQ3rRvU+
> oxKFOg/+JE4aM/TDtofAYwbKa0loyE69N/Ov7evRseKej5VAZNrp92zTRWDXryxp
> 5cMxBhYzwEBnoye0zmALbIqqqwvRz2u2NA2gcG21JshFq7wJZv027ERrfIeXZxeW
> Rm6cI+vQL7oh0kGGo/YupogSVCQqimir2ZrxFDbRtx5qIrl9K9e+a7/hHZvbNmCS
> 60/BjddZnzKoDQtNP0qQ0ip+0MI4THaM8LbUvPQMr69+Wb2OeabIPyxv97tEPC2A
> bZ2npUtrKqkGOLubaejZpgEe8HOzikzsR36ANZdDK07JAkr0RYefiAuna+wtAmMS
> BMGBOq6Geg6SFSBN7mWvihRxeZ/T+QkNj+mxVd3/mU2+Kq7T6xVe2gohleMvRxM1
> IuEzCGTnuydd9j8HPaM369c7R6h7eGGwtVsnIu3886DesDDkQp5Gv8S+7QufWiNE
> rYcnHtVbmaQ00fzZglK9A8RC7I3dzs195DPWNIojt0sjEA0aTAfCE0eW8oBvIoI1
> rpoQCdCKvW9yjocZISwRiKhszaOJrsSpSIwa3qlCPyGc5mICzxCl0toXjjZoR4mG
> HR3Feo/DyBhgNgi8TL9hMoxsbSqkVetkcRarPtshKUGSkjiItM0LtDSPOTPsI3KP
> akhQBJfu7hCZPtQsGfCiJAKLW0G8o7k569K/YapiSGj8KBA/IRA=
> =/jZF
> -END PGP SIGNATURE-
>
> php-7.4.7.tar.xz
> SHA256 hash: 53558f8f24cd8ab6fa0ea252ca8198e2650160649681ce5230c1df1dc2b52faf
> PGP signature:
> -BEGIN PGP SIGNATURE-
>
> iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl7fa2MACgkQkQ3rRvU+
> oxLrehAAkeHnqHPsGR5loVOoTMwifpKzeYJmYamMlTFkIzsxJr3EPDCSaGgPVlvC
> BcMzDPQS//uVrGIjDY9mxe5dO3DZurBm2ubbFPnGeVqpwkGw4HDaGGdvPezxEmnX
> Z+ajmS0gwG/W6B4u9KvqwyrAoC/2aReMo+3B4f1zyPvaD93Z3Kn6f4QXeWhu4l0B
> hmLoV2q6gUDoDK/pe4IR4J3OLHJdwKAIcYVrb9T0dl7Xwis0FjcYoTHLxw1irDaF
> I2AoQi4I7ZP+x16W4Pfb+c83y+771NAymYY17taAHiHTfWwUCaKMg5usf01cn2QG
> wfgeWzH8JC75o5OyP3j1Hgz6QJTj0XlWhF3+X50yIFbxsuIDC0rj3Ki1jsSKKmgg
> nhjsDPBDgTx768yeJMSbPNUwmrjqqM1c0ksu9BkTG1/c6cCewBw02PUcbmwihNZo
> 56chxvb6Jleq7NYR2T3ibfWXvRkY8bhQuBFRTtnj8Q6Z+zukNmP/yoBKYDZORRig
> sSEZVkidT0rVdb19TCJsJX+B9wCLsK2qnO0zGV0eO+lqVJ0e5o0a0dOrH5FNtju/
> uccdSXdCouxAZguhIq6xXyrbi25O5KUM3mK+hvJaTiGz4Izj+PvBq0rSiswBz5Nn
> KEiP7WB8f6UVslUKoDuoanJFFArtehQOnAcndGZO3WHDYQ9dZkI=
> =LNCt
> -END PGP SIGNATURE-
>
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [RFC] Provide argon2 support for password_hash() from ext/sodium

[David Zuelke]

You're listing libsodium versions 0.15 and 0.13 there, but it should
be 1.0.15 and 1.0.13.

Maybe for everyone's reference: Ubuntu 16.04 LTS comes with no
libargon2, and with libsodium 1.0.8; 18.04 LTS comes with libargon2
and with libsodium 1.0.16.

Debian Stretch has 1.0.11, and 1.0.17 in backports.

On Fri, Apr 5, 2019 at 7:52 PM Sara Golemon  wrote:
>
> I was originally planning to just do this since I thought it'd be
> non-controversial, but while implementing I discovered some gotchas, so I'm
> putting it to the group for discussion.  Please give attention to the
> "Backward Incompatible Changes" section.
>
> https://wiki.php.net/rfc/sodium.argon.hash
>
> -Sara

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

[PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?

[David Zuelke]

Hi all,

Would it not be lovely to have, say, two new constants, that contain
the date (ISO, UTC, I guess) of when the running PHP series will be
end-of-maintenance and end-of-life?

Of course PHP_VERSION_SERIES_EOM_DATE and PHP_VERSION_SERIES_EOL_DATE
are a little verbose, but...

It would be really useful for e.g. code check systems, tools like
Composer, hosting platforms, to inform the user of an upcoming or past
EOM/EOL date, without having to maintain a list of these dates
separately (by copying from, or scraping, php.net/eol.php).

Does that sound useful to anyone? It would of course be problematic in
cases where the EOL date is yet to be determined, or changes later (as
it happened with the 5.6 extension), but given that there would still
be newer releases after such a case, where the value of the
constant(s) could then be updated, that'd probably not be so
problematic.

Trivial? Not? Great? Bad? RFC worthy?

Regards,

David

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

Re: [PHP-DEV] On fixing DOMNameSpaceNode and DOM NS API Inconsistency Problems

[David Zuelke]

I agree this should be fixed. It's pretty hilarious how this exact
case (fiddling with the xmlns prefix) is the only comment for
DOMElement::setAttributeNS:
http://php.net/manual/en/domelement.setattributens.php (although
unnecessary, as you don't have to "add namespaces" to a document, that
automatically happens internally).

My hypothesis as to why this special class even exists, and why it is
all implemented this way: whoever wrote that code didn't know about
this "hard-coded" part of the spec, or the spec wasn't even fully
finished regarding that part at that time.

For those who are curious, it's defined in Section 3 of the
"Namespaces in XML 1.1 (Second Edition)" spec:
https://www.w3.org/TR/2006/REC-xml-names11-20060816/#ns-decl

However, pay particular attention to the following note (emphasis mine):

"The prefix xmlns is used only to declare namespace bindings and is by
definition bound to the namespace name http://www.w3.org/2000/xmlns/.
It **must not be declared or undeclared**. Other prefixes must not be
bound to this namespace name, and it must not be declared as the
default namespace. Element names must not have the prefix xmlns."

The DOM Level 2 specification section 1.1.8 ("XML Namespaces")
contains another related definition:

"Note: In the DOM, all namespace declaration attributes are by
definition bound to the namespace URI:
"http://www.w3.org/2000/xmlns/";. These are the attributes whose
namespace prefix or qualified name is "xmlns". Although, at the time
of writing, this is not part of the XML Namespaces specification
[Namespaces], it is planned to be incorporated in a future revision."

This means that both "xmlns:foo" and "xmlns" attributes are both in
this "hard-coded" namespace.

Both of these cases are already handled correctly by, I assume, the
underlying libxml; if you set "xmlns:blah" or "xmlns" qualified name
attributes in that namespace:

$doc = new DOMDocument();
$root = new DOMElement("root");
$doc->appendChild($root);
$root->setAttributeNS("http://www.w3.org/2000/xmlns/";, "xmlns:foo", "urn:bar");
$root->setAttributeNS("http://www.w3.org/2000/xmlns/";, "xmlns", "urn:baz");
$root->setAttributeNS("urn:lol", "erp:foo", "whatup");
echo $doc->saveXML();

the namespace "xmlns" does not get declared, and PHP/libxml correctly produce:




Honestly, I can't imagine there being much code around that even
relies on any of the internal classes, at least not code that deserves
to be broken, because it was written by clowns who to this day would
claim that XML is terrible, when in fact they simply didn't understand
how namespaces work, that prefixes are irrelevant, and that XML
shouldn't be parsed with regular expressions ;)

There is really no use case in the DOM that ever requires anyone to
directly deal with "xmlns" attributes, as their creation (and removal)
is something that just happens automatically; the only real case where
you even have to worry about prefixes is with
DOMElement::setAttributeNS(), where you can cause prefix collisions.
But even that is trivial; internally, the mappings always get
optimized, e.g. in the case of duplicate prefixes for the same
namespace URI:

$doc = new DOMDocument();
$root = new DOMElement("root");
$doc->appendChild($root);
$root->setAttributeNS("urn:lol", "prefixone:foo", "whatup");
$root->setAttributeNS("urn:lol", "prefixtwo:bar", "whatup");
echo $doc->saveXML();

becomes, correctly:




Anyway, I think an RFC and maybe some test cases would be good. I'll
be happy to help dig out my old XML-fu and help :)

David

On Tue, Mar 12, 2019 at 11:54 PM Benjamin Eberlei  wrote:
>
> Hi everyone,
>
> While looking for things to work on in php-src my friend Thomas pointed me
> to a peculiar special case in ext/dom that leads to massive inconsistency
> problems in the API.
>
> There is an undocumented class DOMNameSpaceNode that gets returned from
> DOMElement::getAttributeNode(NS) if you select an attribute that represents
> a namespace (xmlns). This special case is intentionally handled in the
> code, contrary to Pythons DOM Extension which doesn't do this and contrary
> to the DOM Specification, which does not have a special DOMNameSpaceNode.
> Its all DOMAttr.
>
> Problematically DOMNameSpaceNode doesn't extend from DOMAttr, you cannot
> pass this class to DOMElement::removeAttributeNode(DOMAttr $attr):
>
> Fatal error: Uncaught TypeError: Argument 1 passed to
> DOMElement::removeAttributeNode() must be an instance of DOMAttr, instance
> of DOMNameSpaceNode given
>
> Code example here: https://3v4l.org/jkC5s
>
> In addition the DOMNameSpaceNode renames all properties compared to
> DOMAttr, clearly violating the interface documented here
> http://php.net/manual/de/domelement.getattributenode.php
>
> Two potential fixes come to mind:
>
> 1. Have DOMNameSpaceNode extend DOMAttr - maybe this was the originally
> intended behavior, becuase the properties are all named differently?
> 2. Have DOMElement::removeAttributeNode accept also a DOMNameSpaceNode

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3

[David Zuelke]

On Tue, Jun 26, 2018 at 6:32 PM Kalle Sommer Nielsen  wrote:
>
> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov :
> > If you have a minor deprecation in mind, but were too lazy to write an RFC
> > for it, please write me a mail until tomorrow, so that it might be included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> As suggested in the past, I would like to add the following to this
> list (if its not too late):
>
>  - The (real) type-cast and its function, is_real(). There doesn't
> seem to be any support for reals in settype() anyway (side note: in
> the implementation of settype() it claims "double" is deprecated)
>  - Function variants that already exists as constants, php_sapi_name()
> > PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc

Keep in mind you can do phpversion("extensionname"), so that function
at least can't be removed, as the constant doesn't provide the same
functionality.

David

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

Re: [PHP-DEV] FPM maintainership?

[David Zuelke]

Yeah I was going to say: work with Jakub, he has some good stuff in flight! :)

On Wed, Feb 21, 2018 at 11:52 AM, Jakub Zelenka  wrote:
> Hey
>
> On Wed, Feb 21, 2018 at 12:42 AM, Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> I'd like to raise the question of FPM SAPI maintainership. Is it still
>> maintained? If so, by whom? Jerome Loyet is listed as a maintainer, but
>> his last commit has been in 2012, as far as I can see, and I see no
>> activity from him on the bug tracker for the last couple of years (maybe
>> more). FPM is a pretty important module and widely used, and we have
>> over 100 bugs in the bug DB for it, not being addressed. Would anyone
>> like to step up for his module? If not, what's the plan for keeping it
>> alive and well?
>>
>
> I actually work on some parts of FPM and trying to help with some PR's
> already. Currently I work on the rewrite of zlog and as part of that I
> completely rewrote the test framework which is inconvenient for some
> scenarios (especially logging but there are other parts that the current
> tests are not good for). All work is currently done on my FPMi project repo
> [1] which is meant to be a dev version of FPM and potentially separated
> SAPI that can bring the next features sooner to users on the older PHP
> versions. I also started working to the tool for better testing some time
> ago [2]. It's currently just a simple fastcgi client but plan to resume
> work on it and extend it so it can be used for regression testing and
> recreating some bugs that are not possible to do in PHP tests.
>
> The zlog part is more or less working but needs optimization (better
> buffering) and some final improvements and fixes. That's probably most
> wanted feature especially for Docker execution. Then I would like to use
> the new testing framework for all tests and look to other issues.
>
> I already work on it and not sure if there is any other dev actively works
> on it so I would be happy to step up as a maintainer whatever it means :) I
> want however keep working on my plan so the current priority is to sort the
> logging out because it is causing many issues.
>
> [1] https://github.com/bukka/fpmi/compare/0.1.0...next
> [2] https://github.com/bukka/fpmt
>
> Cheers
>
> Jakub

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

[PHP-DEV] Trivial 7.2 opcache segfault

[David Zuelke]

I'm trying to understand this one: https://bugs.php.net/bug.php?id=75837

Is that related to the optimizations in 7.2 around unused local
variables? Can that somehow be triggered by the @ operator? It's such
a trivial reproduce case, it seems almost silly that this hasn't come
up during testing...

David

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

Re: [PHP-DEV] PHP 7.2.0 RC6 Released

[David Zuelke]

Is it really going to be Nov 30, or Nov 23?

On Thu, Nov 9, 2017 at 2:36 PM, Sara Golemon  wrote:
> The sixth (and likely final) release candidate for 7.2.0 was just
> released and can be
> downloaded from:
> https://downloads.php.net/~pollita/
> Or using the git tag: php-7.2.0RC6
>
> The Windows binaries are available at: http://windows.php.net/qa/
>
> Please test it carefully, and report any bugs in the bug system.
> This is out last chance to catch bugs before the final release in three weeks.
> Barring unforeseen calamity, everyone should expect 7.2.0-final on
> Thusday, November 30th.
>
> As a reminder to internals@, any bug fixes should be committed to the
> PHP-7.2 branch as usual, but since we're in the final stretch for
> release, you MUST notify Remi and I of fixes you wish us to
> cherry-pick onto the 7.2.0 release.
>
> Hash Values and GPG signatures can be found below and at:
> https://gist.github.com/sgolemon/f6d308713c286a82f520091fc9dcf445
>
> Thank you, happy testing, and yay 7.2!
> -Sara
>
> php-7.2.0RC6.tar.gz
> SHA256 hash: ad528a8db319e444ce4ca259dec5afeb9d39287e9a6b214e11397cd985207b1d
> PGP signature:
> -BEGIN PGP SIGNATURE-
> iQItBAABCAAXBQJaAaCcEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXIqGhAA
> 3X55n7ODqp/uPFMpjKgyMtWB7kLVbxthZeai/Dvrsd35j2ZOPd9KNYjWFWV8fNWp
> 8jYj1LioW+FPpltlREaMxDXE7/cIZITRUX/k6jAfuafacLR5jy4OE5ghwDbyVnJ0
> Sf6CA92chvnEEp3XTeS6XkPxJAi1H3zp/9KIGTlpFN5IIeaxqCl62hcc0+ikcYP0
> dXm8j8hjqpXuOz2MEVKASmqKPayw27RaUfAE6lI/nuMdva++b7bKQL9tr7Tz+R/J
> 8Wl995Og5GKRhzTj65Uv/uv3cP5hGBqRYjybWIzA7y+offL+TFe12c2HHjBvAIFv
> PtHuky4ZSNbLdarRfmdYs6bUoPx7GMIZDZ6mhGMXqJudh4I5rHt6g/zucZEAJRjk
> V+h8J6pd80wNvoO7KtdnowGJtYjWQAwdr5KB0CmYpGrhogEjr62MvCjm2KvsiO+T
> HTt4tKIkvjNSYwMApIxkNhxpRazEe6+goELoKACAZMwvLw2LLpV4Sg/BebdzAUFe
> 7odLVIDLgoG3OYxEMAzKDKTygRlfhGclxtQlRlmoP4u7Z+AruuGUA/L7n18iD093
> lu0pksrkPIhQrQLydbNrgJfM54XxWBUCq5v3Ka2vJOzwrM+9ekZopPSkfiBfcAoM
> 6ptC0H1nNrlu6eF9xu+oDHsTMZL7HJMOABNdKy9TO5o=
> =Aq+R
> -END PGP SIGNATURE-
>
> php-7.2.0RC6.tar.bz2
> SHA256 hash: 906a13bafbec40a185208846195f11c8c5f6e8bc5672fd37862e95754b978de3
> PGP signature:
> -BEGIN PGP SIGNATURE-
> iQItBAABCAAXBQJaAaCgEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXISIA//
> UOzi+RIfEBFNDsVBRhJQhBoM8eQTe8aHL+RstHmDL2tqakBi4HyvjRdRGMIExSyb
> JCtx1y9KCPfJtPW4Xl/QTFJIslNhWEHsSFSxRVeozrA7tbpKVicW6xs7jr//EBqB
> 8SyoWjO+Rzr8Buvu8XvsxVxOmtNDgbssklcYMILIZHkaN1JGYy+u592W83anEGiv
> H7Ysj/TY6i5YWsSwQVUV0DnkUJ2VeBBjeBQGSJ+SuQGV2dmrvx+k40O/DEysIF8U
> SferVWGkB9NY/nkbxcC0oQRu6Eoh4SGtlUIl9qzPr8/qA6hEfAG3ftfJaQS2qKYv
> gTbKniCr31oQeGeULa0zNZsMkvA15wjjoa6P/LFljr7X3OuJ+naCRB/pwlgnAjwL
> LtNsxzXEnrTiVoSBU/jdG7acoEPmyixu6budROCs30QUnRYq4cCDUDZwqINkSDyI
> rY5NC/O8BVuAiEtFv3alOcUgxmCYsbKDV6fqThSXpdP6aEF35/OgQH7WYp+9eYoE
> mHpvWyIeeAGeAGASGoiuf0zftBEXfCrdgE034xr+/a744rYFakY54Wh3D/d26jc8
> kaQoDNPws4GZwjkvp6EiFTg/1nhQ36SdhmKxnp3ZlZ96cNUUV0PNUnxsHqZms129
> /K9iNMZGBH3pRPiwXoyZbkzLlVQncXp8iKTwaLOI/sk=
> =gOX+
> -END PGP SIGNATURE-
>
> php-7.2.0RC6.tar.xz
> SHA256 hash: be4df00ff5b66e9f13c83e1d08d1d5384ae7ccc820e26f7e5f9e660011496a9e
> PGP signature:
> -BEGIN PGP SIGNATURE-
> iQItBAABCAAXBQJaAaCgEBxwb2xsaXRhQHBocC5uZXQACgkQ29s5dHDRIXJowxAA
> 2JpSoiECsGdsKGu1mBGRnKcFj+SsukSQ+VOeO5vysbrpKhBhc6ooJCRAydu+ez6/
> rvxqzVQFX/aBOTJq878V+ysMs15kaqJsnUPHmqZ8NAubh3vSnXKsqzGEjherG7ju
> t11tZ0lDTMRrM95y0Nrmkgv07UG+JDTBPJF1lVI7b16KezV7bsNKlASwWmIHpsCO
> RyJJjCvaDEgm/rWGQBCdRJra1GjA9eoWVxujnpBztTtlwi+vP0e8KRMziXiv4RG7
> Maj+0Vyni77x2bvAugpDbTmxQAVPwBYOjhBued19savcO51SnFVNJJPr/2KpQq/4
> oOKK2ZHwRn4NBOQb9RK+gcY/KaDg2o1bvYbmUumagAaXjtBN1oRSvLhynVkj850R
> Cobvo8+nAgEDJ9cd6TR6Zc9TOoAjA2fxcl4fknGDGnpZfajK5ISqZ0gqvkimeDIl
> vsKlXdn0M3WhpdikozUjbHx23F15ug4IMGDvpoWh8aMLzxOsCjSszgNWj3QBObZr
> 7ujFtQ/8ryD4el34FlSumA0KBpWG6JBdTUp05VO3cmZELKTld9u7MPvdV/QSAVmo
> HkdJjYQlY8rqk+DI52JJ84Dlj2cvY2PE46m/pUsKnVhesJ01FH5aG7gbBHSbM7I5
> WKj2jbK1Geasw6X0q/ZxTwiNgUlPrlhbJugu7yiZpd0=
> =EDtn
> -END PGP SIGNATURE-
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

[PHP-DEV] libsodium version target for 7.2

[David Zuelke]

Hi all,

The standalone sodium extension has been changed a few days ago to require 
libsodium 1.0.9: 
https://github.com/jedisct1/libsodium-php/commit/e4d6d281cf197deb0086b592a72f282905ba7ead

Will this version requirement also be ported to the PHP-7.2 branch?

The reason I'm asking is because the current Ubuntu LTS (16.04) has version 
1.0.8 of libsodium, and IMO that's an important platform to take into 
consideration. The next LTS (18.04) isn't due until mid 2018.

Cheers,

David


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

Re: [PHP-DEV] PHP 7.1.4 is available

[David Zuelke]

The changelog is incomplete; stops at iconv. 
https://github.com/php/php-src/commit/330a7b62c3558aa987ee80e12f1914347d3a9eee 
is also missing from NEWS for 7.1.3


> On 13. Apr 2017, at 18:43, Joe Watkins  wrote:
> 
> Evening,
> 
> The PHP development team announces the immediate availability of PHP 7.1.4.
> This is a bug fix release, all PHP 7.1 users are encouraged to upgrade.
> 
> For source downloads of PHP 7.1.4, please visit the downloads page:
> 
> https://www.php.net/downloads.php
> 
> Windows binaries can be found at http://windows.php.net/download
> 
> The list of changes is recorded in the change log:
> http://www.php.net/ChangeLog-7.php#7.1.4
> 
> Follows is verification information.
> 
> Cheers
> Joe
> 
> php-7.1.4.tar.bz2
> SHA256 hash:
> 39bf697836e2760b3a44ea322e9e5f1f5b1f07abeb0111f6495eff7538e25805
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAABCAAGBQJY76qaAAoJEPm6Ctoxy9iecEcH/27ET+GcOEIf9oRKl4ndNjjm
> XTSguNKokk5bwTVBUaFvbujHdbdaDHWGESOu0ZP8T6SaK8h9eK4TRoEajckxjx0o
> BXQXs+3DLpujotpSkx4FGh0CC/1tl8x7CkIq5k8l7Nn14JPA+Ro9wItGbCO7d1dN
> KRN52rqNzgLcFoRoCqK+SLJc6V3Fb9ewdRUU8xo78+60T0cZPqpTeSNXW/Y3Swph
> Ua7uuwSft07Qwiz+T0km1XS8/1s57YatR/nV79rVw0ijNyENc/jz9sV7BxAYcgwt
> UUuZx1BtfhHjrdwM9wsgpm/wG2VrxBQIUe8LXMIkjJwX/VgkPhpkvluzdguOY7A=
> =iggm
> -END PGP SIGNATURE-
> 
> 
> php-7.1.4.tar.gz
> SHA256 hash:
> ed0006c86de503684dde04c6dd811ea2354a3b6d10ebd9f0cb103dcd28f0e70f
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAABCAAGBQJY76qiAAoJEPm6Ctoxy9ieJUgIAK70tYU9dUa+iMUYUksO8Qf2
> 9yi2lX/8QSaaFXYeiUirPKShSQf05vs8FeAzlPBbBGhAoQ5mWA8ivKhlP2/olMJR
> MFakWWJ4Ae/k2Cl2ChlvpqRbhC11xRW2VHbHCMReWuOM1bOdxv1DWUBmFFt/F/b7
> lIn1auVKS+euHtVK5LHpD43pCYW0ouDxG/N1BVrhU2IlSNY7CR7ThjSCrzUDtdu0
> 9Ld1W81+7UJn47KWScq25gAXoUizF1DeJI3S7X40hNOStDWxUA/VcsbBybtsh1jw
> U07CrWB/DeK1/LMe6iLpDoFPSHQHmpxVjFkb+2fryRBJWjkZ+s1YPH+xum9E8/g=
> =CWU9
> -END PGP SIGNATURE-
> 
> 
> php-7.1.4.tar.xz
> SHA256 hash:
> 71514386adf3e963df087c2044a0b3747900b8b1fc8da3a99f0a0ae9180d300b
> PGP signature:
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAABCAAGBQJY76qlAAoJEPm6Ctoxy9ieiacH/iREeJqVqGU6eevvXBFrJmEj
> nK2XTg59PHKYAXxg5h6Sq3xREvW2JLZYW9Bx49I6Zk+dxMY7kqSHKEftqthG2GtD
> clGx5NOhlQySnFcyHVMSuElL/sWaKWURERENAXHZerv0n1k9FJP0wuJy6DBNxHFM
> 6eRFJ/7lY9HcVG/OKps5DOJkI6+RHUwZ5Yad37I1nQcsgfutWaASLHYKNRw3nTRn
> Xg0PTGarviNJCkm2CyGwXRYQpBzpd+YQuHN9/tjKyY471VYkGSTw3kUWgA9tyzeP
> Wy99JVKS5/8wWLGtC6VuvQoPy+Qd186rpCRgB9RDF4RD6sg/CyX6nxErMqIP/EE=
> =D+kM
> -END PGP SIGNATURE-


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

Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

[David Zuelke]

Thanks; NEWS entry is missing though!

And it unfortunately *just* missed the 7.0.18 branch cutoff :(

Or can it be merged to PHP-7.0.18, given how problems would be caught in 
7.1.4RC1 testing? ;)



> On 28. Mar 2017, at 22:10, Nikita Popov  wrote:
> 
> On Mon, Mar 27, 2017 at 10:58 PM, David Zuelke  wrote:
> Just another poke to surface it, in case this should be merged into the 7.0 
> branch as well :)
> 
> https://bugs.php.net/bug.php?id=74250
> 
> I've applied 
> https://github.com/php/php-src/commit/d6f70f0ee3d5f595a9f6dadaabda834a1d47c662
>  to 7.0. The rest is not relevant.
> 
> Nikita


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

Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

[David Zuelke]

Just another poke to surface it, in case this should be merged into the 7.0 
branch as well :)

https://bugs.php.net/bug.php?id=74250


> On 19. Mar 2017, at 23:39, David Zuelke  wrote:
> 
> Thanks for the fixes, Nikita!
> 
> Will they be merged to the PHP-7.0 branch as well?
> 
> 
>> On 14 Mar 2017, at 16:39, Nikita Popov  wrote:
>> 
>> On Tue, Mar 14, 2017 at 11:29 AM, David Zuelke  wrote:
>> Hi all,
>> 
>> There appears to be a performance regression in the CFG and DFA based 
>> optimization passes of OPcache in PHP 5.6+ when loading huge classes (such 
>> as those generated by Symfony's routing component) for the first time.
>> 
>> The issue does not occur on PHP 5.5. Tests below are with 5.6.30, 7.0.16 and 
>> 7.1.2 and default INI settings; I replicated the issue on both macOS and 
>> Linux.
>> 
>> Test file here (it's from an actual application, slightly anonymized, not a 
>> synthetic example): 
>> https://gist.github.com/dzuelke/fe867f55f09e0bf79ecefcc815b7fe92
>> 
>> Without OPcache, everything is fine in all versions:
>> 
>> $ time -p php -dopcache.enable_cli=0 hugeclass.php
>> real 0.10
>> user 0.09
>> sys 0.00
>> 
>> With OPcache on, things are suddenly much, much slower:
>> 
>> 5.6:
>> 
>> $ time -p php -dopcache.enable_cli=1 hugeclass.php
>> real 3.23
>> user 3.21
>> sys 0.02
>> 
>> 7.0:
>> 
>> $ time -p php -dopcache.enable_cli=1 hugeclass.php
>> real 1.76
>> user 1.73
>> sys 0.02
>> 
>> 7.1:
>> 
>> $ time -p php -dopcache.enable_cli=1 hugeclass.php
>> real 4.01
>> user 3.98
>> sys 0.02
>> 
>> For comparison, 5.5 is as speedy as you'd expect it to be:
>> 
>> $ time -p php -dopcache.enable_cli=1 hugeclass.php
>> real 0.14
>> user 0.11
>> sys 0.02
>> 
>> If we switch off optimization passes 5 (CFG based) and 6 (DFA based, only in 
>> 7.1), everything is great again in all versions:
>> 
>> $ time -p php -dopcache.enable_cli=1 -dopcache.optimization_level=0x7FCF 
>> hugeclass.php
>> real 0.13
>> user 0.10
>> sys 0.02
>> 
>> For 5.6 and 7.0, pass 6 is not a thing, but in 7.1, we can inspect passes 5 
>> and 6 separately.
>> 
>> Pass 5 (CFG based) already makes for a drastic performance hit in 7.1:
>> 
>> $ time -p php -dopcache.enable_cli=1 -dopcache.optimization_level=0x7FDF 
>> hugeclass.php
>> real 0.88
>> user 0.86
>> sys 0.01
>> 
>> But pass 6 (DFA based) is the one that causes the biggest slowdown in 7.1:
>> 
>> $ time -p php -dopcache.enable_cli=1 -dopcache.optimization_level=0x7FEF 
>> hugeclass.php
>> real 3.29
>> user 3.24
>> sys 0.04
>> 
>> In all versions, subsequent loads from the cache (such as when running FPM 
>> or the built-in web server) are fast.
>> 
>> Is this slowness with a cold cache expected/accepted, or does that qualify 
>> as a bug?
>> 
>> Yes, this is a bug. Optimization should never be this slow.
>> 
>> From a quick perf run, the problem in the DFA pass is that TI is quadratic 
>> in the number of calls (as call lookup is implemented as a linear scan). 
>> This can be fixed with a more efficient map lookup.
>> The problem in the CFG pass is that a large buffer is zeroed repeatedly.
>> 
>> Nikita
> 


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

Re: [PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

[David Zuelke]

On 14 Mar 2017, at 16:39, Nikita Popov  wrote:
> 
> On Tue, Mar 14, 2017 at 11:29 AM, David Zuelke  wrote:
>> Hi all,
>> 
>> There appears to be a performance regression in the CFG and DFA based 
>> optimization passes of OPcache in PHP 5.6+ when loading huge classes (such 
>> as those generated by Symfony's routing component) for the first time.
>> 
>> 
>> 
>> Is this slowness with a cold cache expected/accepted, or does that qualify 
>> as a bug?
> 
> Yes, this is a bug. Optimization should never be this slow.
> 
> From a quick perf run, the problem in the DFA pass is that TI is quadratic in 
> the number of calls (as call lookup is implemented as a linear scan). This 
> can be fixed with a more efficient map lookup.
> The problem in the CFG pass is that a large buffer is zeroed repeatedly.

Alright, thanks! I opened a bug for it: https://bugs.php.net/bug.php?id=74250



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

[PHP-DEV] OPcache compilation performance regression in PHP 5.6/7 with huge classes

[David Zuelke]

Hi all,

There appears to be a performance regression in the CFG and DFA based 
optimization passes of OPcache in PHP 5.6+ when loading huge classes (such as 
those generated by Symfony's routing component) for the first time.

The issue does not occur on PHP 5.5. Tests below are with 5.6.30, 7.0.16 and 
7.1.2 and default INI settings; I replicated the issue on both macOS and Linux.

Test file here (it's from an actual application, slightly anonymized, not a 
synthetic example): 
https://gist.github.com/dzuelke/fe867f55f09e0bf79ecefcc815b7fe92

Without OPcache, everything is fine in all versions:

$ time -p php -dopcache.enable_cli=0 hugeclass.php 
real 0.10
user 0.09
sys 0.00

With OPcache on, things are suddenly much, much slower:

5.6:

$ time -p php -dopcache.enable_cli=1 hugeclass.php
real 3.23
user 3.21
sys 0.02

7.0:

$ time -p php -dopcache.enable_cli=1 hugeclass.php
real 1.76
user 1.73
sys 0.02

7.1:

$ time -p php -dopcache.enable_cli=1 hugeclass.php
real 4.01
user 3.98
sys 0.02

For comparison, 5.5 is as speedy as you'd expect it to be:

$ time -p php -dopcache.enable_cli=1 hugeclass.php 
real 0.14
user 0.11
sys 0.02

If we switch off optimization passes 5 (CFG based) and 6 (DFA based, only in 
7.1), everything is great again in all versions:

$ time -p php -dopcache.enable_cli=1 -dopcache.optimization_level=0x7FCF 
hugeclass.php
real 0.13
user 0.10
sys 0.02

For 5.6 and 7.0, pass 6 is not a thing, but in 7.1, we can inspect passes 5 and 
6 separately.

Pass 5 (CFG based) already makes for a drastic performance hit in 7.1:

$ time -p php -dopcache.enable_cli=1 -dopcache.optimization_level=0x7FDF 
hugeclass.php
real 0.88
user 0.86
sys 0.01

But pass 6 (DFA based) is the one that causes the biggest slowdown in 7.1:

$ time -p php -dopcache.enable_cli=1 -dopcache.optimization_level=0x7FEF 
hugeclass.php
real 3.29
user 3.24
sys 0.04

In all versions, subsequent loads from the cache (such as when running FPM or 
the built-in web server) are fast.

Is this slowness with a cold cache expected/accepted, or does that qualify as a 
bug?

David


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

Re: [PHP-DEV] [RFC][Vote] Libsodium vote closes; accepted (37-0)

[David Zuelke]

Will there be a renaming of the "libsodium" extension on PECL to "sodium" as 
well, and will the two codebases be kept in sync?

Otherwise, libraries cannot, using Composer, express a dependency on 
"ext-sodium".


> On 10.02.2017, at 22:04, Scott Arciszewski  wrote:
> 
> The vote for the Libsodium RFC has been closed. The final tally is 37 yes,
> 0 no.
> 
> I'll begin working on the implementation with the desired API (sodium_*
> instead of \Sodium\*).
> 
> Thank you for everyone who participated in these discussions over the past
> year or so and, of course, everyone who voted for better cryptography in
> PHP 7.2.
> 
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 


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

Re: [PHP-DEV] Fixing Apache mod_proxy_fcgi SCRIPT_FILENAME et al for good

[David Zuelke]

> On 17.01.2017, at 15:58, Remi Collet  wrote:
> 
> Le 17/01/2017 à 15:44, David Zuelke a écrit :
>> Hi all,
>> 
>> https://github.com/php/php-src/pull/694 and 
>> https://github.com/php/php-src/pull/765 brought support for Apache's 
>> "SetHandler" based mod_proxy_fcgi-to-FPM interface.
>> 
>> Recently, a change in Apache 
>> (https://github.com/apache/httpd/commit/cab0bfbb2645bb8f689535e5e2834e2dbc23f5a5)
>>  broke this again, so FPM no longer works with Apache 2.4.23 and later.
>> 
>> The HTTPD developers are interested in fixing this once and for all, by 
>> cleaning up several inconsistencies on their side in one go. However, that 
>> would require accompanying changes on the PHP side in all of the FPM and 
>> FCGI SAPI's detection logic, and that needs coordinating :)
>> 
>> What's the right place for this discussion? Would somebody with the right 
>> karma/experience be willing to sign up to 
>> https://httpd.apache.org/lists.html#http-dev and join in? Or does a GitHub 
>> issue or PR suffice?
> 
> Can you please describe how this is broken,
> Which config / url, with expected / actual results ?

See https://github.com/php/php-src/pull/694#issuecomment-267183973 ff and 
https://github.com/apache/httpd/commit/cab0bfbb2645bb8f689535e5e2834e2dbc23f5a5#commitcomment-20393588
 ff

I should point out that right now, this does not require action on the PHP 
side, as the change will be reverted for the next Apache release; I started 
this discussion to address the fact that Apache and PHP/FPM are mutually 
depending on specific magic/workarounds, which is not easy to solve without 
some coordination :)

> P.S. I'm running apache 2.4.25 and php-fpm without (noticed issue)

Are you using SetHandler, or another method? SetHandler is the only one that 
universally works with arbitrary .htaccess rewrites etc, unlike ProxyPass.

The issue also only arises when rewriting to e.g. an index.php

David



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

[PHP-DEV] Fixing Apache mod_proxy_fcgi SCRIPT_FILENAME et al for good

[David Zuelke]

Hi all,

https://github.com/php/php-src/pull/694 and 
https://github.com/php/php-src/pull/765 brought support for Apache's 
"SetHandler" based mod_proxy_fcgi-to-FPM interface.

Recently, a change in Apache 
(https://github.com/apache/httpd/commit/cab0bfbb2645bb8f689535e5e2834e2dbc23f5a5)
 broke this again, so FPM no longer works with Apache 2.4.23 and later.

The HTTPD developers are interested in fixing this once and for all, by 
cleaning up several inconsistencies on their side in one go. However, that 
would require accompanying changes on the PHP side in all of the FPM and FCGI 
SAPI's detection logic, and that needs coordinating :)

What's the right place for this discussion? Would somebody with the right 
karma/experience be willing to sign up to 
https://httpd.apache.org/lists.html#http-dev and join in? Or does a GitHub 
issue or PR suffice?

David

P.S. obviously, the 5.6 active support EOL timing isn't ideal for such a 
change, but we can cross that bridge when we get there ;)


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

[PHP-DEV] Schedule for next releases?

[David Zuelke]

Happy new year everyone!

I haven't seen this mentioned here on the list, and figured I'd ask, as it 
makes some people's lives a bit easier to know this... :)

What's the schedule/plan for the next point releases for PHP? The last ones 
were four weeks ago, but there haven't been the usual RC tags for the new ones 
two weeks ago. Will this interval be skipped entirely, or does the schedule 
just shift?

And will there be one last 5.6 release with outstanding bug fixes?

Cheers!

David


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

Re: [PHP-DEV] PHP 5.6 end of active support

[David Zuelke]

On 14.12.2016, at 16:15, Dennis Clarke  wrote:
> 
> On 12/14/2016 06:35 AM, Kalle Sommer Nielsen wrote:
>> Hi
>> 
>> On Dec 14, 2016 12:23, "Christoph M. Becker"  wrote:
>>> 
>>> Hi!
>>> 
>>> The end of active support for PHP 5.6 is documented to be on December,
>>> 31th[1].  Does that mean that there'll be no further release with
>>> "normal" bug fixes (but only security fixes)?
>> 
>> Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc
>> 
> 
> This is entirely too soon. At the present moment neither of the PHP 7.0
> releases will compile clean on a strict POSIX environment. At all. The
> version 5.6.x tree is perfectly stable and works out of the box without
> an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
> compile. I guess I need to file more bug reports

Yes, you do. PHP 7.0.0 was released a year ago.

> and push through this
> or the 5.6.x version will be dropped with no valid replacement that

5.6 will receive security fixes for another 24 months.

> works in a strict environment.  Perhaps the gcc compiler is an absolute
> requirement and if that is true then the code isn't acceptable to any
> other compiler regardless if it is C99 compliant or otherwise.

It appears to be, from looking at https://bugs.php.net/bug.php?id=67229, but 
that affects PHP 5 as well, not just 7.

David


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

Re: [PHP-DEV] Bumping minimal OpenSSL version to 1.0.1 in master for PHP 7.1

[David Zuelke]

On 13.12.2016, at 11:31, Niklas Keller  wrote:
> 
> OpenSSL support for 1.0.1 will end this year.
> 
> Support for version 1.0.1 will cease on 2016-12-31. No further releases of
>> 1.0.1 will be made after that date. Security fixes only will be applied to
>> 1.0.1 until then.
>> Version 1.0.0 is no longer supported.
>> Version 0.9.8 is no longer supported.
> 
> 
> We dropped 0.9.8 and 1.0.0 in 7.1.
> 
> Should we drop support for 1.0.1 in master, so it's dropped for 7.2 then,
> as it will be unsupported then?

Please no.

Ubuntu's 14.04 LTS is on 1.0.1f and gets security backports. EOL is April 2019.

Unless there is a hard reason (API changes or whatever) that PHP 7.2 absolutely 
cannot live without, it's a bad idea, as folks on 14.04 or similar (think RHEL 
etc) then have to either rely on third parties for updates, or vendor in a 
newer version, even though their system libssl is still receiving security 
updates.

David


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

Re: [PHP-DEV] PHP 7.1.0 GA

[David Zuelke]

On 22.11.2016, at 19:36, Joe Watkins  wrote:

> Evening internals,
> 
> I'm excited to announce that PHP 7.1.0 will be GA on December 1st.
> 
> It has taken a lot of hard work from a lot of people, so stop whatever you
> are doing and give those people a round of applause.
> 
> Cheers
> Joe

Good stuff. A++, would use again :)

Does it make sense to delay 7.1.1 by a week so its release cycle syncs up with 
that of 5.6 and 7.0? They're due on January 5, while 7.1.1 would be due Dec 28 
right now.

David



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

Re: [PHP-DEV] Do You think PHP's SOAP client should have an option to virtuallyAdd (for XSD imports!) missing end-slash in the URI to WSDL? I do!

[David Zuelke]

I think it should not. Your pull request fixes a problem in that WSDL.

The WSDL is located at the URL 
`https://pg.eet.cz/eet/services/EETServiceSOAP/v3?wsdl`.

It references an XML Schema file at `EETXMLSchema.xsd`, which is a relative 
location, so it's looked for relative to the containing document, at 
`https://pg.eet.cz/eet/services/EETServiceSOAP/EETXMLSchema.xsd`.

The correct location is 
`https://pg.eet.cz/eet/services/EETServiceSOAP/v3/EETXMLSchema.xsd`, but that's 
not PHP's problem. You should contact the owner of the service and ask them to 
fix the issue. Not only PHP, but all other clients that adhere to the spec will 
be unable to load this file, so it's in their interest to get it resolved.

Failing that, you can

1. use an XML catalog entry on your local system to re-define where 
`EETXMLSchema.xsd` is located;
2. load the WSDL file from the origin URL, cache it locally, and rewrite the 
`schemaLocation` to contain a full relative path 
(`/eet/services/EETServiceSOAP/v3/EETXMLSchema.xsd`) or even an absolute URL. 
Then load that local WSDL.

You really want to do option 2 in production anyway, because otherwise, your 
SoapClient instantiation will fetch the remote WSDL file on each instantiation, 
which slows down your app, and may break things even if you don't make a SOAP 
call if the endpoint is down.

If you want to discuss this further, then the PR on GitHub is the right spot 
for discussing this.


> On 20.09.2016, at 10:02, Filip Rydlo  wrote:
> 
> Hello to all PHP developers!
> 
>  If You are interested how we could improve SOAPClient a bit,
> please, see my last comment here to understand my *WHYs*. :-)
> 
> 
> *https://github.com/php/php-src/pull/2121
> *
> 
> 
>  This pull request is in no way complete. It is just a small start to
> let us *track down* the exact code-path *where the problem occurs.*
> 
>  Sadly, the example scenario (HOW to reproduce) contains a *webservice*
> which *only works* from *PCs / I.P.s*  *located  in Czech Republic,
> EU.*Hopefully,
> some of You also live there... or possibly You have some testing virtual
> webserver located there. :)
> 
> 
>  *I would be happy to test the new feature!*   But I am still unable
> to compile PHP5 from the sources on Debian 8.5 x64  because of some module
> called *opcache :-(*
> 
> 
> 
> 
>   Here is the error I am getting. I am sure it is a well known error
> for You ... and You certainly know the solution. Unfortunatelly,  I am not
> so good in linux development,  yet.
> Maybe You could tell me how to overcome / workaround this problem,
> please?.That would be GREAT !  :-)
> I already tried all the classical solutions I could *google-out¨ *and
> installing all the dependencies did not solve *this*.
> 
> Thank You so much.
> 
> Filip The Overtonesinger
> 
> 
>  ERROR compiling php *5.6.24* sources:
> --
> 
> /bin/bash /home/bob/A_php5/php-src/libtool --silent --preserve-dup-deps
> --mode=link cc -DPHP_ATOM_INC -I/home/bob/A_php5/php-src/include
> -I/home/bob/A_php5/php-src/main -I/home/bob/A_php5/php-src
> -I/home/bob/A_php5/php-src/ext/date/lib -I/usr/include/libxml2
> -I/home/bob/A_php5/php-src/ext/sqlite3/libsqlite
> -I/home/bob/A_php5/php-src/TSRM -I/home/bob/A_php5/php-src/Zend
> -I/usr/include -g -O2 -fvisibility=hidden -DZEND_SIGNALS-o ext/opcache/
> opcache.la -export-dynamic -avoid-version -prefer-pic -module -rpath
> /home/bob/A_php5/php-src/modules  ext/opcache/ZendAccelerator.lo
> ext/opcache/zend_accelerator_blacklist.lo
> ext/opcache/zend_accelerator_debug.lo ext/opcache/zend_accelerator_hash.lo
> ext/opcache/zend_accelerator_module.lo ext/opcache/zend_persist.lo
> ext/opcache/zend_persist_calc.lo ext/opcache/zend_file_cache.lo
> ext/opcache/zend_shared_alloc.lo ext/opcache/zend_accelerator_util_funcs.lo
> ext/opcache/shared_alloc_shm.lo ext/opcache/shared_alloc_mmap.lo
> ext/opcache/shared_alloc_posix.lo ext/opcache/Optimizer/zend_optimizer.lo
> ext/opcache/Optimizer/pass1_5.lo ext/opcache/Optimizer/pass2.lo
> ext/opcache/Optimizer/pass3.lo ext/opcache/Optimizer/optimize_func_calls.lo
> ext/opcache/Optimizer/block_pass.lo
> ext/opcache/Optimizer/optimize_temp_vars_5.lo
> ext/opcache/Optimizer/nop_removal.lo
> ext/opcache/Optimizer/compact_literals.lo ext/opcache/Optimizer/zend_cfg.lo
> ext/opcache/Optimizer/zend_dfg.lo ext/opcache/Optimizer/dfa_pass.lo
> ext/opcache/Optimizer/zend_ssa.lo ext/opcache/Optimizer/zend_inference.lo
> ext/opcache/Optimizer/zend_func_info.lo
> ext/opcache/Optimizer/zend_call_graph.lo ext/opcache/Optimizer/zend_dump.lo
> Reloading web server: apache2 failed!
> Apache2 is not running ... (warning).
> Makefile:870: recipe for target 'ext/opcache/opcache.la' failed
> make: *** [ext/opcache/opcache.la] Error 1


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

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

[David Zuelke]

On 20.03.2016, at 22:10, David Zuelke  wrote:
> 
> On 10.03.2016, at 16:56, David Zuelke  wrote:
>> 
>>> On 08.03.2016, at 16:18, Andrea Faulds  wrote:
>>> 
>>> Hi,
>>> 
>>> David Zuelke wrote:
>>>> Is this intentional? Related to opcache's "can only be built shared" 
>>>> status? But why would that trigger static builds? Or is it a bug?
>>> 
>>> While we're at it, why is Opcache still built as shared? Does something 
>>> prevent it being statically-linked?
>> 
>> I remember something about PCRE and whether or not that's linked statically 
>> or not. Can't find it right now.
>> 
>> Either way, it'd be great if someone in-the-know could chime in on this 
>> matter ;)
> 
> Just a little *bump*... anyone got any idea here?
> 
> Thanks!

And another *bump*... anyone from Zend maybe?


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

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

[David Zuelke]

I think this solution is merely a band-aid for a more profound architectural 
weakness of current PHP setups, where a web server call out to the engine (via 
embedding or FastCGI) to execute a script, which causes this recurring 
initialization overhead in the first place.

The future is (or should be) servers implemented fully in PHP code (e.g. 
PHP-PM), just like every other comparable language (Ruby, Python, Java, ...) 
already does. That also brings many other benefits, such as the ability to 
handle upgrades to WebSockets in the same codebase, stream request bodies as 
they're being uploaded, and so forth.

And the performance figures that PHP-PM delivers with Symfony validate that 
approach IMO.


> On 13.04.2016, at 17:55, Lin Yo-An  wrote:
> 
> Hi internals,
> 
> 
> The javascript engine V8 uses a strategy called "startup snapshot" to
> optimize app load time (see
> http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more
> details)
> 
> The approach used by V8 creates a snapshot from heap, so the V8Context
> could be reused directly without re-running the bootstraping code.
> 
> I think running javascript app in the browser is somehow like we run php
> script for each requests where the app bootstrapping code is required to be
> executed repeatedly for each request.
> 
> Currently, our opcache extension can cache the byte codes, but the byte
> codes still need to be executed every time when bootstrapping an app, and
> which increases the overhead for each request.
> 
> For example, a lot of applications use composer to initialize the class
> loader via the statement below:
> 
>require "vendor/autoload.php";
> 
> The statement above produces thousands of byte code to run, which is to
> make an app ready. (If you use vld extension to show the opcodes)
> 
> However, if we can support a simple syntax to describe what is doing
> "bootstrap", we are able to create a startup snapshot from it.
> 
> 
> The proposal here want to introduce some new syntax to optimize app load
> time though the below syntax:
> 
>bootstrap "vendor/autoload.php";  // caches the context after running
> this script.
> 
> Or
> 
>bootstrap {
>   require "vendor/autoload.php";
>   // do something else for making app ready
>};
> 
> And of course, we might detect the bootstrap script automatically without
> creating new syntax and opcodes, but I think it's hard to do because PHP
> applications can be written by many ways...
> 
> 
> Questions
> 
> 
> I don't know if this approach is doable or not. Or maybe we can support
> this in a separated extension instead of changing the zend core?
> 
> Do you guys think it's doable? would you like to share your idea for this?
> 
> 
> 
> 
> 
> 
> Best Regards,
> 
> Yo-An Lin


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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

On 21.03.2016, at 23:44, Anatol Belski  wrote:
> 
> What I'm suggesting to do is using a bit finer comb checking with the real
> life situations. Fe what would be the win for the user, either having to
> enable JIT by hand, or to disable it in a rare case. Currently, as for me,
> the latter seems still to be a more feasible option. At some point some due
> consideration could be reached, but I don't see the today's point as such.
> As long as we still handle over 99% of the usage cases with a simple JIT
> stack increase, it is IMHO more than balanced. The option of falling back to
> no JIT could be still kept in mind as it's most likely won't cause any
> compatibility issue.

Yeah no doubt. The trouble is that not always is the cause of the error very 
clear. I'd guess most code out there doesn't use preg_last_error() to figure 
out what went wrong and report that back, making it look like there simply was 
no match, so there's likely a lot of unknown cases, of which just some will 
emerge over time.

What adds to the trouble is that it depends on the subject string, and not just 
on the pattern. So maybe people's existing tests won't catch it.

How about defaulting JIT to off (or at least setting it to 0 in both the 
recommended dev and prod INIs that ship with PHP) until an automatic fallback 
has been implemented?



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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

On 21.03.2016, at 19:41, Anatol Belski  wrote:
> I've just pushed a fix for this issue, could you please check? A global
> stack space
> Is used in a thread safe manner. I was first setting max to 256K, then
> decreased it
> To 64K for now. My tests on Linux and Windows show your snippet passing,
> Travis is good as well.

Just tested; that fix works for my specific test case, thanks!

However, if I just increase the size of the JSON by adding a bunch of package 
definitions, it starts failing again, so this really is just a temporary 
band-aid, and we should consider falling back to retrying without JIT, or 
switching that off by default in php.ini.

The particular composer.json I showed is generated on deploy based on a 
customers' composer.lock (to correctly resolve PHP versions and extensions to 
be installed), and there will be a day when a customer with more dependencies 
comes along (or maybe that's already happened and they just have not filed a 
ticket), which means the 64k again won't be enough.

My workaround for now is to disable pcre.jit via php.ini, but maybe that really 
should be the default.

Regards,

David


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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

On 21.03.2016, at 19:54, Nikita Popov  wrote:
> 
> On Mon, Mar 21, 2016 at 7:41 PM, Anatol Belski  wrote:
>> The issue I have with more increasing the stack is that - while as we see
>> till today
>> the default stack size of 32K is enough in the common case, the max of it
>> will be
>> reserved. So the real usage will most likely stay under 32K, but the whole
>> of max
>> (say 64K now) will be unusable by anything else.
>> 
> Are you sure about that? The documentation says "The arguments are a starting 
> size for the stack, and a maximum size to which it is allowed to grow." 
> Unless I'm misunderstanding something, it should not be allocating the 
> maximum size right away.

That's how I understood it too.


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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

> On 20.03.2016, at 22:41, Anatol Belski  wrote:
> 
> Hi,
> 
>> -Original Message-----
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Sunday, March 20, 2016 10:10 PM
>> To: Anatol Belski 
>> Cc: Christoph Becker ; Pierre Joye
>> ; PHP internals 
>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>> 
>>> On 17.03.2016, at 05:22, David Zuelke  wrote:
>>> 
>>>> On 16.03.2016, at 21:38, Anatol Belski  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>>> -Original Message-
>>>>> From: David Zuelke [mailto:d...@heroku.com]
>>>>> Sent: Tuesday, March 15, 2016 11:58 PM
>>>>> To: Anatol Belski 
>>>>> Cc: Christoph Becker ; Pierre Joye
>>>>> ; PHP internals 
>>>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>>>>> 
>>>>> Sure. So composer creates patterns to parse a file dynamically; I
>>>>> have not figured out why it only happens for some composer.json
>>>>> files (or maybe it happens for all of them and I just have not
>>>>> noticed), but this example here I extracted from a reproducibly
>>>>> failing "composer require" run; it runs into the JIT stack size limit
> on PHP 7
>> while it works fine on 5.x:
>>>>> 
>>>>> https://gist.github.com/dzuelke/cc64a630c14416eda3e9
>>>>> 
>>>> I've just tried this on Debian Jessie and on Windows with the latest
> 7.0.x
>> builds, in both cases the error is PREG_BACKTRACK_LIMIT_ERROR. I'd be next
>> asking you to check the configuration. Runtime like system or ini, or
> build config
>> can affect this. Anyway, I don't see an issue with PCRE JIT at the moment.
>>> 
>>> Sorry, I simplified the example too far. Updated it again to throw a JIT
> stack
>> limit error again (but works fine with "php -dpcre.jit=0"):
>>> 
>>> https://gist.github.com/dzuelke/cc64a630c14416eda3e9/de7b7293798ac57b4
>>> f75d822dc22a625be0fe9df
>> 
>> Were you able to reproduce this? :)
>> 
> Yes, it is reproducible. I was just investigating on another issue
> https://bugs.exim.org/show_bug.cgi?id=1803 which now seems unrelated. With
> the JIT stack - we can try to use a custom stack to increase its size by
> allocating a custom jit stack of an increased sizeas a workaround. If that
> works, it should be fine. I'll be working on a patch next week, then we can
> see this option makes sense. More on the topic is readable here
> http://www.pcre.org/original/doc/html/pcrejit.html#stackcontrol .

That sounds good. I suspect a significantly larger stack size than the PCRE 
default of 32k will do the job for most cases. Arguably, what Composer uses 
there is not a trivial pattern with all the nesting going on, but I was unable 
to simplify it when I took a few minutes the other day, and while the 
composer.json where the bug occurs is generated by code, I don't think it 
qualifies as an extreme case.

I guess though that some day, someone with a more complex pattern and/or 
subject string will come with the same problem and say "this fails for me, the 
256k stack limit you set in PHP is not enough", so maybe an INI option should 
exist? Although that's not terribly useful if one program needs it for one 
pattern. Flags don't work well for this (unless it's e.g. a numeric one 
indicating multiples of 128k or something, but that's also terrible).

Or change the pcre_match (et al) implementations to retry without JIT if the 
error occurs?

David


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

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

[David Zuelke]

On 10.03.2016, at 16:56, David Zuelke  wrote:
> 
>> On 08.03.2016, at 16:18, Andrea Faulds  wrote:
>> 
>> Hi,
>> 
>> David Zuelke wrote:
>>> Is this intentional? Related to opcache's "can only be built shared" 
>>> status? But why would that trigger static builds? Or is it a bug?
>> 
>> While we're at it, why is Opcache still built as shared? Does something 
>> prevent it being statically-linked?
> 
> I remember something about PCRE and whether or not that's linked statically 
> or not. Can't find it right now.
> 
> Either way, it'd be great if someone in-the-know could chime in on this 
> matter ;)

Just a little *bump*... anyone got any idea here?

Thanks!




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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

> On 17.03.2016, at 05:22, David Zuelke  wrote:
> 
>> On 16.03.2016, at 21:38, Anatol Belski  wrote:
>> 
>> Hi,
>> 
>>> -----Original Message-
>>> From: David Zuelke [mailto:d...@heroku.com]
>>> Sent: Tuesday, March 15, 2016 11:58 PM
>>> To: Anatol Belski 
>>> Cc: Christoph Becker ; Pierre Joye
>>> ; PHP internals 
>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>>> 
>>> Sure. So composer creates patterns to parse a file dynamically; I have not
>>> figured out why it only happens for some composer.json files (or maybe it
>>> happens for all of them and I just have not noticed), but this example here 
>>> I
>>> extracted from a reproducibly failing "composer require" run; it runs into 
>>> the JIT
>>> stack size limit on PHP 7 while it works fine on 5.x:
>>> 
>>> https://gist.github.com/dzuelke/cc64a630c14416eda3e9
>>> 
>> I've just tried this on Debian Jessie and on Windows with the latest 7.0.x 
>> builds, in both cases the error is PREG_BACKTRACK_LIMIT_ERROR. I'd be next 
>> asking you to check the configuration. Runtime like system or ini, or build 
>> config can affect this. Anyway, I don't see an issue with PCRE JIT at the 
>> moment.
> 
> Sorry, I simplified the example too far. Updated it again to throw a JIT 
> stack limit error again (but works fine with "php -dpcre.jit=0"):
> 
> https://gist.github.com/dzuelke/cc64a630c14416eda3e9/de7b7293798ac57b4f75d822dc22a625be0fe9df

Were you able to reproduce this? :)

David



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

Re: [PHP-DEV] OpenSSL ext status including port to OpenSSL 1.1

[David Zuelke]

On 20.03.2016, at 20:50, Jakub Zelenka  wrote:
> 
> Hi,
> 
> I just wanted to send a quick update about my recent work on openssl ext in
> case someone else wanted to start something similar so we don't have a
> wasted effort on that. :)
> 
> 1. Error queueing
> 
> I'm more or less done with a patch for error storing and clearing OpenSSL
> error queue:
> 
> https://github.com/php/php-src/compare/PHP-7.0...bukka:openssl_error_store

Good stuff! Just FYI, there has been decent progress on the discussion around 
how to make libpq behave better with openssl errors (that's what I think 
prompted this change originally by way of a ticket); looks like that'll land in 
the next point release(s). But since other extensions' libs may also use 
openssl, the same issue can arise again anytime, so storing the errors 
ourselves on the PHP side is a great change that fixes all (well, most of) 
those potential issues in one sweep.


> I have been slowly working on a more complete test for openssl_error_string
> that will cover most real error cases. There is still quite a lot of work
> that I need to do but the incomplete test can be seen here:
> 
> https://github.com/bukka/php-util/blob/master/tests/openssl/openssl_error_string_basic.phpt
> 
> The idea is that I would like to create a PR against 7.0 after I'm happy
> with that test so it can be tested by others and then merged. Then I plan
> to merge the AEAD work that is complete but overlaps slightly with this one
> so I want to merge it after that...

Any plans to port that back to 5.6 as well? I'd really love to see that, 
considering how it fixes real issues in the wild, and how long the security fix 
phase for 5.6 will be.


> 2. OpenSSL 1.1 port
> 
> I have got a port of the extension to work on OpenSSL 1.1. There has been
> quite a bit of changes mainly due to the fact that most structures are now
> opaque (but also some other changes)

I assume 1.0.whatever-is-in-ubuntu will remain usable? Or do we plan on 
requiring 1.1 in, say, 7.1?

Thanks for all your hard work on this Jakub!

David


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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

> On 16.03.2016, at 21:38, Anatol Belski  wrote:
> 
> Hi,
> 
>> -Original Message-----
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Tuesday, March 15, 2016 11:58 PM
>> To: Anatol Belski 
>> Cc: Christoph Becker ; Pierre Joye
>> ; PHP internals 
>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>> 
>> Sure. So composer creates patterns to parse a file dynamically; I have not
>> figured out why it only happens for some composer.json files (or maybe it
>> happens for all of them and I just have not noticed), but this example here I
>> extracted from a reproducibly failing "composer require" run; it runs into 
>> the JIT
>> stack size limit on PHP 7 while it works fine on 5.x:
>> 
>> https://gist.github.com/dzuelke/cc64a630c14416eda3e9
>> 
> I've just tried this on Debian Jessie and on Windows with the latest 7.0.x 
> builds, in both cases the error is PREG_BACKTRACK_LIMIT_ERROR. I'd be next 
> asking you to check the configuration. Runtime like system or ini, or build 
> config can affect this. Anyway, I don't see an issue with PCRE JIT at the 
> moment.

Sorry, I simplified the example too far. Updated it again to throw a JIT stack 
limit error again (but works fine with "php -dpcre.jit=0"):

https://gist.github.com/dzuelke/cc64a630c14416eda3e9/de7b7293798ac57b4f75d822dc22a625be0fe9df

David



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

Re: [PHP-DEV] [RFC] Libsodium (bump)

[David Zuelke]

I think I've said this before; please call it ext-sodium, not ext-libsodium.

David


> On 15.03.2016, at 18:40, Scott Arciszewski  wrote:
> 
> Link to RFC: https://wiki.php.net/rfc/libsodium
> 
> I'd like to bump the RFC to make Libsodium a core extension, as per
> Ferenc's suggestion on the mcrypt RFC.
> 
> Question: If this extension is adopted, which syntax would you prefer?
> 
>\Sodium\func()
>Sodium::func()
>sodium_func()
> 
> As it currently stands, the PHP extension in PECL uses a namespace +
> function format.
> 
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 


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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

On 15.03.2016, at 21:18, Anatol Belski  wrote:
> 
> Hi,
> 
>> -Original Message-
>> From: David Zuelke [mailto:d...@heroku.com]
>> Sent: Sunday, March 13, 2016 6:09 AM
>> To: Anatol Belski 
>> Cc: Christoph Becker ; Pierre Joye
>> ; PHP internals 
>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>> 
>> Just wanted to resurrect this thread... I just got a JIT stack size limit
> error (which
>> Composer reports as "unknown error" because it has no logic for the new
>> constant) while running "composer require somepackage" with PHP 7 and JIT
>> enabled.
> Could you please give a worky reproduce scenario? Itself the description
> sounds like that some part in composer is not yet PHP7 ported or it's a
> special case causing JIT impacts, but it were good to have a reproducer to
> evaluate and make a conclusion. Till today, there was no bug reports about
> PCRE JIT issues in common PHP frameworks. Except this special case
> https://bugs.exim.org/show_bug.cgi?id=1189 which is fixed in PCRE 8.39 that
> should be bundled as soon as possible (an eye is being kept on that).

Sure. So composer creates patterns to parse a file dynamically; I have not 
figured out why it only happens for some composer.json files (or maybe it 
happens for all of them and I just have not noticed), but this example here I 
extracted from a reproducibly failing "composer require" run; it runs into the 
JIT stack size limit on PHP 7 while it works fine on 5.x:

https://gist.github.com/dzuelke/cc64a630c14416eda3e9


>> IMO, a pattern modifier would be good so that applications can disable JIT
> on
>> demand.
>> 
>> I'd also like to re-start a discussion on changing the default for
> pcre.jit to 0.
> A pattern modifier could be thinkable and would be doable (sure for master,
> or even for later 7.0 versions), but would cause some increased complexity
> in logic for pattern cache. From the above - let's have a reproducer and
> evaluate the status. Then we'll have a point for further consideration.
> 
> Thanks
> 
> Anatol
> 
>> 
>>> On 04.08.2015, at 23:20, Anatol Belski  wrote:
>>> 
>>> Hi Christoph,
>>> 
>>>> -Original Message-
>>>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
>>>> Sent: Tuesday, August 4, 2015 7:40 PM
>>>> To: Anatol Belski ; 'Christoph Becker'
>>>> ; 'Pierre Joye' 
>>>> Cc: 'PHP internals' 
>>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>>>> 
>>>> On 04.08.2015 at 16:33, Anatol Belski wrote:
>>>> 
>>>>>> -Original Message-
>>>>>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
>>>>>> Sent: Tuesday, August 4, 2015 1:16 PM
>>>>>> To: Anatol Belski ; 'Christoph Becker'
>>>>>> ; 'Pierre Joye' 
>>>>>> Cc: 'PHP internals' 
>>>>>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>>>>>> 
>>>>>> I didn't mean to store all patterns in both variants, but rather as
>>>>>> requested.  Say, the PHP script starts with pcre.jit=0, so all
>>>>>> patterns will be stored studied without JIT.  Then the script
>>>>>> changes to pcre.jit=1.  Following cache lookups check whether an
>>>>>> already cached pattern was studied with JIT.  If not, a new cache
>>>>>> entry is made with the pattern studied with JIT (that new entry may
>>>>>> replace the old one or not; not sure what's best).  Changing back
>>>>>> to
>>>>>> pcre.jit=0 will again keep the old patterns, but ensures that only
>>>>>> those which
>>>> have been studied without JIT are retrieved from the cache.
>>>>> It needs to replace the old entry, the regex string is used as key.
>>>>> At least per
>>>> current mechanism. When user changes the JIT config, I'd see it like
>>>> as an obvious hint. Like pcre.jit=0 - no more JIT study from now on.
>>>> 
>>>> Probably you're right that replacement is best.  However, the key is
>>>> the full regex string (including modifiers), AFAIK, and Adam already
>>>> came up with the idea that choosing between JIT and non-JIT might be
> done
>> via a new modifier[1].
>>>> Something to consider, if it turns out that there is some real
>>>> optimization potential for userland to choose between both variants on
> a
>> case-by-case basis.
>>> Yeah, that were a nice approach. Should be checked probably, whether
> there's
>> a corresponding perl pattern modifier (probably there is none, but
> shouldn't be
>> that bad). And also to evaluate what behavior were produced when say jit
> is
>> disabled but a modifier is passed.
>>> 
>>>>> Probably it would be needed to save the study flags with the cache
>>>>> entry, looks
>>>> like the pcre_cache_entry struct should have a gap for that.
>>>> 
>>>> If I'm not mistaken, an additional flag wouldn't be necessary,
>>>> because the pcre_extra struct has the executable_jit field, which could
> be
>> queried.
>>> Ok, that would be even better, given it's reliable.
>>> 
>>> Regards
>>> 
>>> Anatol
>>> 
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
>>> visit: http://www.php.net/unsub.php
> 
> 

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

Just wanted to resurrect this thread... I just got a JIT stack size limit error 
(which Composer reports as "unknown error" because it has no logic for the new 
constant) while running "composer require somepackage" with PHP 7 and JIT 
enabled.

IMO, a pattern modifier would be good so that applications can disable JIT on 
demand.

I'd also like to re-start a discussion on changing the default for pcre.jit to 
0.


> On 04.08.2015, at 23:20, Anatol Belski  wrote:
> 
> Hi Christoph,
> 
>> -Original Message-
>> From: Christoph Becker [mailto:cmbecke...@gmx.de]
>> Sent: Tuesday, August 4, 2015 7:40 PM
>> To: Anatol Belski ; 'Christoph Becker'
>> ; 'Pierre Joye' 
>> Cc: 'PHP internals' 
>> Subject: Re: [PHP-DEV] PCRE JIT stack size limit
>> 
>> On 04.08.2015 at 16:33, Anatol Belski wrote:
>> 
 -Original Message-
 From: Christoph Becker [mailto:cmbecke...@gmx.de]
 Sent: Tuesday, August 4, 2015 1:16 PM
 To: Anatol Belski ; 'Christoph Becker'
 ; 'Pierre Joye' 
 Cc: 'PHP internals' 
 Subject: Re: [PHP-DEV] PCRE JIT stack size limit
 
 I didn't mean to store all patterns in both variants, but rather as
 requested.  Say, the PHP script starts with pcre.jit=0, so all
 patterns will be stored studied without JIT.  Then the script changes
 to pcre.jit=1.  Following cache lookups check whether an already
 cached pattern was studied with JIT.  If not, a new cache entry is
 made with the pattern studied with JIT (that new entry may replace
 the old one or not; not sure what's best).  Changing back to
 pcre.jit=0 will again keep the old patterns, but ensures that only those 
 which
>> have been studied without JIT are retrieved from the cache.
 
>>> It needs to replace the old entry, the regex string is used as key. At 
>>> least per
>> current mechanism. When user changes the JIT config, I'd see it like as an
>> obvious hint. Like pcre.jit=0 - no more JIT study from now on.
>> 
>> Probably you're right that replacement is best.  However, the key is the 
>> full regex
>> string (including modifiers), AFAIK, and Adam already came up with the idea 
>> that
>> choosing between JIT and non-JIT might be done via a new modifier[1].
>> Something to consider, if it turns out that there is some real optimization
>> potential for userland to choose between both variants on a case-by-case 
>> basis.
>> 
> Yeah, that were a nice approach. Should be checked probably, whether there's 
> a corresponding perl pattern modifier (probably there is none, but shouldn't 
> be that bad). And also to evaluate what behavior were produced when say jit 
> is disabled but a modifier is passed.
> 
>>> Probably it would be needed to save the study flags with the cache entry, 
>>> looks
>> like the pcre_cache_entry struct should have a gap for that.
>> 
>> If I'm not mistaken, an additional flag wouldn't be necessary, because the
>> pcre_extra struct has the executable_jit field, which could be queried.
>> 
> Ok, that would be even better, given it's reliable.
> 
> Regards
> 
> Anatol
> 
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

[David Zuelke]

> On 08.03.2016, at 16:18, Andrea Faulds  wrote:
> 
> Hi,
> 
> David Zuelke wrote:
>> Is this intentional? Related to opcache's "can only be built shared" status? 
>> But why would that trigger static builds? Or is it a bug?
> 
> While we're at it, why is Opcache still built as shared? Does something 
> prevent it being statically-linked?

I remember something about PCRE and whether or not that's linked statically or 
not. Can't find it right now.

Either way, it'd be great if someone in-the-know could chime in on this matter 
;)

David


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

[PHP-DEV] Enabling opcache causes libraries to build as static

[David Zuelke]

Hi all,

I've been trying to get to the bottom of why even a minimal PHP build (any 5.x 
or 7 release, or a fresh e.g. 7.0 branch checkout after buildconf) creates .a 
versions of all shared extensions in addition to .so modules.

I've narrowed it down to opcache:

$ ./configure --disable-all
...
checking whether to build shared libraries... yes
checking whether to build static libraries... no

versus

$ ./configure --disable-all --enable-opcache=shared
...
checking whether to build shared libraries... yes
checking whether to build static libraries... yes

but I cannot figure out why this is happening (both on OS X and Ubuntu 14.04).

Is this intentional? Related to opcache's "can only be built shared" status? 
But why would that trigger static builds? Or is it a bug?

I've been wading through config.m4s, generated configures etc but still haven't 
found the reason; any pointers or explanations would be much appreciated!

Cheers,

David


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

Re: [PHP-DEV] NEWS entries

[David Zuelke]

On 28.02.2016, at 13:24, Tom Sommer  wrote:
> 
> I'm reading the 7.0.4 NEWS file[1] and I get the policy of just writing the 
> bug number and headline, but in a lot of cases the bug report headline says 
> nothing about the actual problem, or the actual fix.
> 
> For instance:
> 
> Fixed bug #71559 (Built-in HTTP server, we can download file in web by bug). 
> (Johannes, Anatol)
> Fixed bug #71474 (Crash because of VM stack corruption on Magento2). (Dmitry)
> Fixed bug #71443 (Segfault using built-in webserver with intl using symfony). 
> (Laruence)
> 
> Would it not be an idea to write what was fixed, instead of what was broken?

No. IMO, it's good practice for change logs to describe the problem for fixes, 
and the change or addition for changes or additions.

Maybe for something like "php-fpm dumped core", the description can be expanded 
to include the reason ("php-fpm dumps core on SIGQUIT"), but that's much better 
than "Fix: call zend_signal_init() again on FPM startup", because it gives you 
no idea of what the problem was, which is important for users looking at (or 
searching through) changelogs to figure out if an update addresses a problem 
they're experiencing.

David



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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[David Zuelke]

On 09.02.2016, at 15:33, Derick Rethans  wrote:
> 
> On Tue, 9 Feb 2016, Zeev Suraski wrote:
> 
>> 1.  "Debate the technical issues, and never attack a person's opinion. 
>> People will disagree, so be it."
>> 
>> I think this sentence is problematic.  Not that I'm pro-attacks, but 
>> opinions - as ideas - should absolutely be up for scrutiny and debate.  
>> What I think we should say instead is this:
>> 
>> "Debate the ideas, never attack the person holding them."
>> 
>> Criticizing ideas is absolutely fine, and it's healthy.  Ideas can be 
>> bad even if they don't have any 'technical issues' in them.  It's the 
>> personal attacks we should avoid.  And of course, the criticism should 
>> be to-the-point - but the proposed text already covers that.
>> 
>> We can consider adding another important part of the equation - "Don't 
>> consider critique of an idea you proposed as critique of you 
>> personally."  As humans, we tend to do that, and we shouldn't.
> 
> I've changed it to:
> 
> * Debate the technical issues, and ideas behind them, but never attack the
>  person holding them. People will disagree, so be it.

I agree with Zeev here. It would be good to simplify this, and adding an 
explicit note about the inverse as well.

Something like:

"Debate issues and ideas, not the person holding them. Regardless of what side 
of a discussion you're on, realize that criticism of ideas or actions is 
distinct from criticism of a person."

David



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

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

[David Zuelke]

Thanks for the work, Derick. Looks good!

(aaand I just top-replied :p)


> On 09.02.2016, at 13:33, Derick Rethans  wrote:
> 
> Hello!
> 
> Things have quieted down around the Code of Conduct and Contributor 
> Guidelines process, but I have not been sitting still. In the last week, 
> the following things happened:
> 
> - I had a call with the Drupal Community Working Group - as suggested by 
>  Larry Garfield. Stanislav was on the call as well.
> 
>  Take aways:
> 
>  - Texts should be void from ambiguity.
> 
>  - Although their CWG dealt with plenty of cases, no punitive action 
>has occured as parties would often step back themselves. In most 
>cases, a gently reminder was all that was necessary.
> 
>  - We should be reluctant to limit the scope of the Code of Conduct and 
>Contributor Guidelines.
> 
>  - A Code of Conduct without *any* 'teeth' would not be beneficial.
> 
>  - We should start with suggesting/nominating people for the Mediation 
>Team *before* deciding on the procedures and guidelines that 
>they should mediate around. The underlaying reason is that if the 
>team is known upfront, there ought to be more understanding for the 
>general developer community. Or in other words, there should be no 
>reason that "I would only put my friends on it".
> 
>I do however have a few people in mind that I will reach out to 
>privately, to see whether they are interested. If you have any 
>suggestions for people that you consider reliable, considerate, and 
>empathic, please reach out to them yourself, or let me know and I 
>will.
> 
> - The RFC text has seen a few updates as well.
> 
>  - @jessamynwest improved some of the text for "encouraged behaviour"
>
> https://github.com/derickr/php-community-health/commit/134670974b000483c2a179a02fc05a6d2de85d97
>  - @hnrysmth imported some new phrases from the Contributor Covenant 
>1.4 over
>
> https://github.com/derickr/php-community-health/commit/8ca9fe70538b036a938acbafa5f5f27f91228602
>  - @connerbw added a more general blurb about PHP and the commitment of 
>the PHP team to be inclusive
>
> https://github.com/derickr/php-community-health/commit/e6c33f4b81975f2b2f27919e37c585322f829a1c
>  - I combined the three bits of text around mailinglist posting 
>guidelines into the Contributor Guidelines 
>
> https://github.com/derickr/php-community-health/commit/7c55d1dd407524cdab593b885e6b3101bf590769
> 
> I feel that the "Contributor Guidelines" are now in a reasonable shape 
> to do a quick poll to gauge acceptability. As this is not a formal RFC 
> vote, it's simply done through an online poll: 
> http://twtpoll.com/y6hs4ndsfiki485
> 
> Voting is non-binding, and will end at Friday February 12th, at noon
> UTC.
> 
> Feel free to reply here with suggestions, comments, etc.
> 
> cheers,
> Derick
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

[David Zuelke]

On 22.01.2016, at 17:43, Florian Anderiasch  wrote:
> 
> On 22.01.2016 15:29, Pierre Joye wrote:
>> 
>> Freshly adopted:
>> 
>> http://rubyonrails.org/conduct/
>> https://golang.org/conduct
>> 
> 
> Ruby (the language) is discussing the adoption of a Code of Conduct
> right now, and several people in that thread issue what I think are
> similar concerns about the wording in the covenant one:
> 
> https://bugs.ruby-lang.org/issues/12004
> 
> AFAICT Rails adopted exactly that one, not sure about slight changes.
> 
> FWIW, I like the Go one a lot better.

Postgres are also working on one: 
http://www.postgresql.org/message-id/5699131d.2040...@commandprompt.com

David



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

Re: [PHP-DEV] Bug #68276 Reproducible memory corruption: pgsql conflicts with openssl extension

[David Zuelke]

On 19.01.2016, at 02:36, Yasuo Ohgaki  wrote:
> 
> Hi David,
> 
> On Tue, Jan 19, 2016 at 2:31 AM, David Zuelke  wrote:
>> 
>> I have customers running into this too. I have not yet had time to pick up 
>> that patch - AFAICT, it's incomplete (see comments).
>> 
>> We are, in parallel, working on getting a fix into libpq, but that's of 
>> course just a band-aid, since it can still happen with any other library 
>> that also uses openssl functions.
> 
> That's what I thought.
> 
>> 
>> The principle approach of that PR ("backing up" the errors from openssl) is 
>> good, though.
> 
> This issue is nasty. I hope you come up with feasible solution soon.

The libpq fix is in the works and not that complex. It's more a question of 
when it would get released (Postgres doesn't do regular release intervals).

The PHP side of it is more work, and genuinely not pretty, but it's not like 
there's an alternative approach to fix it, so we'll have to live with it.

What I am currently struggling with is a way to reproduce this for the tests... 
once libpq is fixed, the problem can't be triggered anymore.

> BTW, should I change the bug report category to openssl?

Yeah it's an ext-openssl "problem" (one could also argue the fault is with 
OpenSSL, but meh).

David


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

Re: [PHP-DEV] Bug #68276 Reproducible memory corruption: pgsql conflicts with openssl extension

[David Zuelke]

> On 18.01.2016, at 03:03, Yasuo Ohgaki  wrote:
> 
> Hi openssl module maintainers,
> 
> This bug https://bugs.php.net/bug.php?id=68276 is categorized
> as pgsql bug, but it would be more appropriate if categorized as
> openssl bug.
> 
> This bug report includes PR https://github.com/php/php-src/pull/1223
> and it seems it7s a good one.
> 
> Could any openssl module maintainer take care of it?

Hi,

I have customers running into this too. I have not yet had time to pick up that 
patch - AFAICT, it's incomplete (see comments).

We are, in parallel, working on getting a fix into libpq, but that's of course 
just a band-aid, since it can still happen with any other library that also 
uses openssl functions.

The principle approach of that PR ("backing up" the errors from openssl) is 
good, though.

David



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

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[David Zuelke]

On 14.01.2016, at 13:18, Zeev Suraski  wrote:

> The way I see it, we don't need to acknowledge having a problem in order to 
> want to improve.  I'm sure that resonates with most developers on this list - 
> wanting to continuously improve does not mean you're saying that things were 
> problematic to begin with.  Instead, it's an assumption which is literally 
> always true - wherever you are, whatever you do, you can always do better.  
> It's true for everything - processes, relationships, code - and mailing list 
> etiquette.
> 
> The right question, IMHO, is do we want to improve?  Do we want to try and be 
> more polite and respectful?  Do we want to try and improve the atmosphere?  
> That's a much easier goal to rally around, I think, and for the most part, I 
> can hardly imagine there won't be consensus around it. 

I really like this line of thinking, and the positivity it projects.

David



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 11.01.2016, at 12:31, Anthony Ferrara  wrote:

> Actually, asking for proof and denying are the same thing. If they
> weren't, then why would you be asking for proof unless you believed it
> didn't happen?

They are not the same thing. If you make a claim, then the onus of proof is on 
you, and you cannot simply turn that reasonable request against them by then 
implying they're denying. Otherwise, why have proof for anything at all?

To me, this begs the question: would you handle incidents covered by the CoC in 
a similar way, with that same attitude? An accuser claims something, and asking 
for proof will be interpreted as denial?

By extension, will a third party asking for proof for an incident be subject to 
kafkatrapping - "the fact that you're doubting X happened means you're also 
guilty of X"? That one has happened to me before on twitter. Didn't stick 
because of the ridiculousness, but maybe the conjured mob was simply not large 
enough to spark sufficient outrage.

I'm pretty uncomfortable that you as the person "in charge" of this RFC hold 
such biased views. If you can't see that asking for proof and denial are 
different things then that IMO disqualifies you for that role.

The same applies to your claims of threats of violence. It's fine if you don't 
want to provide details, but then you can't bring those cases up. It's 
legitimate for others here to ask you for evidence if you do bring it up. I 
understand that we're all different personalities and you're maybe more wired 
in that direction (mentioning something in passing), but you need to understand 
that once a claim is out there, it's up to you to back it up. If you then 
refuse to, it raises doubts, and rightfully so.

Otherwise, we "just have to take your word for it", and that's exactly the 
thing many here are afraid of when it comes to this RFC - that in the future, 
anyone can pull accusations out of their hats, and the accusation is enough, 
because "why would you be making that accusation if it didn't happen" (please 
compare that sentence to the quoted section at the beginning of this message to 
understand why it is relevant.

David


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

Re: [PHP-DEV] [RFC] Libsodium

[David Zuelke]

Can we call that extension "sodium" please without the "lib" prefix?

David


> On 07.01.2016, at 08:26, Scott Arciszewski  wrote:
> 
> Hi everyone,
> 
> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
> include references to the online documentation.
> 
> https://wiki.php.net/rfc/libsodium
> 
> All new functions and classes would exist in the Sodium namespace. e.g.
> 
>$ciphertext = \Sodium\crypto_box($message, $nonce, $keypair);
> 
> This is part of an overall effort to improve PHP's cryptography; up
> next will be the pluggable crypto API that supports multiple backends
> (with a scope limited to openssl and libsodium at the time of release)
> but always provide conservative defaults. Then I'd like to look at
> deprecating ext/mcrypt back to PECL and add more hash functions to
> ext/hash.
> 
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 09.01.2016, at 19:48, Anthony Ferrara  wrote:
> 
> All,
> 
>> I was not hesitant (or, let's maybe call it "intentionally procrastinating") 
>> to post on this topic because I felt unsafe on this list or in the general 
>> realm of the PHP community; I simply was in no mood to deal with a mob of 
>> self-proclaimed-or-not "Social Justice Warriors" and their digital 
>> pitchforks on twitter or elsewhere - and they're already trying: 
>> https://twitter.com/drupliconissad/status/685489458934841344
> 
> Please, let's stop this rhetoric and propaganda. All of you.
> 
> Since day one supporters of a CoC have been attacked. We've been
> called "SJW", "Fascists", "Feminists", and a whole more, and a whole
> lot worse. Have you looked at Reddit? Have you looked at Twitter?
> Hell, David just called us a "mob of self-proclaimed-or-not Social
> Justice Warriors." Outsiders have joined that rally against "SJW" and
> "Fascism" (and that's me being nice as to what they are saying).

This must be a misunderstanding. I did not call you that. I specifically meant 
people outside this discussion (e.g. that account above, apparently created 
specifically for these, say, attacks).

David

P.S: I have not read reddit on this topic (or any other, as I try to stay away 
from that site unless some NASA folks do an AmA :)), or looked at twitter 
beyond my normal feed, since I've been busy with vacationing and some work 
stuff the last few days. Just catching up with this thread. Sorry if I'm 
repeating points already made and/or refuted.



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

(Thank you for this write-up, Brandon. It's good to hear an opinion from 
someone who's a bit closer to that "field". I'll ignore netiquette and top-post 
because it feels like a good point to pick up from and share my general 
thoughts on this)

Personally, I don't disagree with the idea of having a CoC. I think it can be 
greatly beneficial to a community overall.

Adding the "Reasonable Person" test was an important step. I would like to go a 
step further, because there is this section (emphasis mine):

> Project maintainers have the right and responsibility to remove, edit, or 
> reject comments, commits, code, wiki edits, issues, and other contributions 
> that are not aligned to this Code of Conduct, or to ban temporarily or 
> permanently any contributor for other behaviors that they deem 
> inappropriate, threatening, offensive, or harmful.

IMO, the emphasized portion should be changed to demand "objectively" as a 
requirement (e.g. "objectively offensive"), to ensure that the reasonable 
person test is applied. We've seen time and again in this thread how different 
people's perspectives are when it comes to what constitutes an attack or 
offense, and how "fluid" the lines are in people's subjective perception.

Systems where these things are not well-defined and instead open to subjective 
interpretation have the potential to spiral out of control (at varying 
velocities), and that's my main concern.

As an example, look at the minefield that university campuses in the US have 
become in recent years:

> In a particularly egregious 2008 case, for instance, Indiana 
> University–Purdue University at Indianapolis found a white student guilty of 
> racial harassment for reading a book titled Notre Dame vs. the Klan. The book 
> honored student opposition to the Ku Klux Klan when it marched on Notre Dame 
> in 1924. Nonetheless, the picture of a Klan rally on the book’s cover 
> offended at least one of the student’s co-workers (he was a janitor as well 
> as a student), and that was enough for a guilty finding by the university’s 
> Affirmative Action Office.


This is from 
http://www.theatlantic.com/magazine/archive/2015/09/the-coddling-of-the-american-mind/399356/
 - I urge everyone to read it, because it's extremely relevant to this debate.

Such so-called "emotional reasoning" (e.g. "I am offended by this, therefore it 
must be offensive and have been intended as an offense"), is becoming more and 
more common. Situations like these are already happening to members of the 
community, see e.g. https://twitter.com/nateabele/status/684135142915452928 
(and like with Paul, I often disagree with Nate, but shout-out to him for his 
input and in particular for 
https://gist.github.com/nateabele/8d156730dc428322fca5)

I would like to cite another section from the article above to underline this 
point, just in case readers are not interested right now to read it whole first 
and then return:

> The thin argument “I’m offended” becomes an unbeatable trump card. This leads 
> to what Jonathan Rauch, a contributing editor at this magazine, calls the 
> “offendedness sweepstakes,” in which opposing parties use claims of offense 
> as cudgels. In the process, the bar for what we consider unacceptable speech 
> is lowered further and further.

> 

> Since 2013, new pressure from the federal government has reinforced this 
> trend. Federal antidiscrimination statutes regulate on-campus harassment and 
> unequal treatment based on sex, race, religion, and national origin. Until 
> recently, the Department of Education’s Office for Civil Rights acknowledged 
> that speech must be “objectively offensive” before it could be deemed 
> actionable as sexual harassment—it would have to pass the “reasonable person” 
> test. To be prohibited, the office wrote in 2003, allegedly harassing speech 
> would have to go “beyond the mere expression of views, words, symbols or 
> thoughts that some person finds offensive.”
> 
> But in 2013, the Departments of Justice and Education greatly broadened the 
> definition of sexual harassment to include verbal conduct that is simply 
> “unwelcome.” Out of fear of federal investigations, universities are now 
> applying that standard—defining unwelcome speech as harassment—not just to 
> sex, but to race, religion, and veteran status as well. Everyone is supposed 
> to rely upon his or her own subjective feelings to decide whether a comment 
> by a professor or a fellow student is unwelcome, and therefore grounds for a 
> harassment claim. Emotional reasoning is now accepted as evidence.


I fear that as group with (mostly) a programming background (as opposed to a 
legal one), and definitely "armed to the teeth with good intentions", we might 
mess up this crucial aspect of the CoC.

It's become a not-uncommon tendency for people in "modern society" (gah, kids 
these days!) to say "I find this subjectively offensive, therefore it must be 
VERBOTEN", and the threshold for t

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

+1 to all the points below; pretty much my concerns and thoughts exactly.

> On 08.01.2016, at 08:30, Zeev Suraski  wrote:
> 
>> We've seen time and time again that the court of public opinion is a
>> horrific
>> judge for these style issues.
> 
> This sentence has me worried in several different ways.  Would you care to
> provide some references how the court of public opinion was a horrific judge
> for these style issues?
> Secondly, it's the first time (I believe, could be wrong) that the word
> 'style' makes an entrance to this thread.  I thought we were dealing with
> truly unacceptable behaviors like personal attacks and harassment, not
> 'style issues'.
> 
> 
>> I'm 100% open to completely rewriting the RFC, to pulling in a different
>> CoC,
>> to rewriting or reusing a different conflict resolution policy. That's all
>> 100% on
>> the table. However, I will not support what many are suggesting here that
>> people will be required (even if just
>> initially) to report issues publicly.
> 
> I for one don't feel strongly about having to report in public.  I don't
> mind having a private mediation team, personally I think it makes more
> sense.  The problem isn't public vs. private per se.  The problem is with
> this team having judicial powers, and with the RFC providing 'structure for
> persecution'.  Once systems are in place, people start using them - and
> since these systems are going to be inherently flawed (I wrote about that in
> my other emails), that's a recipe for disaster.  And I do agree, the
> combination of a private team AND judicial powers is the worst.
> 
> Private mediation team whose sole purpose is trying to diffuse conflicts -
> sure.  Private [anything] team with jurisdiction, plus some sort of pseudo
> ready-to-execute law as a part of the RFC - won't get my support.
> 
>> Simply look at the level of attacks that me and a few other committers
>> have
>> received by making this proposal. I don't feel comfortable making any of
>> those attacks public (drawing more attention to them). In private, to a
>> team
>> that is trusted and has even a baseline set of "powers" to at least report
>> an
>> incident with identifying details redacted would be far better than just
>> requiring people to "come forward with any issue".
> 
> I'm with Kevin here 100%.
> I just saw your reply to him while writing this.  It has me wondering &
> worried in two additional ways:
> Worried:  You say you don't think they constitute CoC violations.  Do you
> see the problem in that statement?  That's exactly the 'open for
> interpretation' issue we're pointing out. Maybe someone else in your
> position would feel differently and file a case, and plead it strongly
> before a non-professional CoC team and sway them his way?  While there were
> certainly some extreme statements made on this thread, I think a more
> accurate description of them is that none of them came even remotely close
> to being unacceptable.  And here's your difference in interpretation -
> "Probably not a CoC violation" vs. "Not even close to being unacceptable
> behavior".
> Wondering:  If you don't think they're CoC violations, how would this CoC
> help?  On one hand you seem to be pointing to them as a reason why the CoC
> is needed, but on the other, you're saying they probably don't violate it.
> In other words, how is it relevant to the discussion?
> 
>> I think many do agree. If you look at this 225+ reply thread, the vast
>> majority
>> of karma holding people have not responded (even many who frequent this
>> list). A few (5+) of them have reached out to me personally to say that
>> they
>> are explicitly staying out of this discussion because of the level of
>> aggression
>> and tone, but would be willing to support a reasonable proposal (some
>> provided meaningful feedback on it, some support the current revision).
>> 
>> Think about that. People who are long standing members of this community
>> and project do not feel that they can safely respond to this very thread.
>> Think of the irony there.
> 
> To be honest, I thought hard before getting involved in this thread, and not
> for the reasons you think.  Opposing this RFC, IMHO, takes a lot more guts
> than supporting it - as it seemingly a "Let's make the world better, who's
> in favor?" RFC.  Who in his right mind doesn't want to make the world
> better?
> Also, most of the positive responses were before a good case against the RFC
> was established.  In fact, what I'm seeing is that some of the early
> supporters of the RFC changing their mind.
> 
>> One active community member (though does not have karma here) is
>> quoted to say "The tone of the 'discussion' is such that I wouldn't dream
>> of
>> throwing in 2 cents, let alone attempt to spearhead real and lasting
>> change".
> 
> If this RFC was accepted, would we be banning or otherwise taking measures
> against anybody based on it?
> If yes, let's discuss it right now because this is very worrisome.
> If not, how i

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 06.01.2016, at 03:58, Kevin Smith  wrote:
> 
>> You state this like some kind of self-evident truth. Understand that not 
>> everybody agrees with you, and scorn is not generally something that wins 
>> people round to your argument.
> 
> If a code of conduct so broad and invasive that it seeks deal with such 
> crimes as the “thoughtless use of pronouns” and “culturally insensitive 
> names” isn’t speech-policing, what is?

Where does it say that though? Did I miss something?


> 
>>> 
>>> The "real and legitimate issues" can be addressed without
>>> one, perhaps with the "conflict resolution" document you referenced. It
>>> is orders of magnitude more reasonable
>> 
>> Ah, some constructive suggestions. More of this please.
> 
> You may not see much of Paul’s engagement in this discussion as constructive, 
> but I would disagree, and it doesn’t look like I’m alone. Many codes of 
> conduct are written by well-intentioned people unskilled in legislation and 
> enforced by tribunals unskilled in investigation and adjudication. Pair that 
> up with the sort of person who earnestly believes they are making the world a 
> better place by controlling what others say and how they say it, who deems 
> any opinion they don’t like “dangerous" and any pushback they receive 
> “harassment"—those sorts of people do exist, and they readily abuse 
> extrajudicial systems—and you’ve got the recipe for gross injustice levied 
> against people with an unpopular opinion. This does not require knowingly bad 
> actors. Everyone involved would be not just cleared but congratulated by 
> their own consciouses for doing what is Right and Good.

"The road to hell is paved with good intentions"...


> Knowing Paul to some degree, I doubt he’s merely using “fascism” as a 
> general, inflammatory descriptor. Make no mistake, a project is not the same 
> thing as a political nation-state. Still, the Contributor Covenant that was 
> put forward as the original CoC does have some fascistic tendencies, 
> including the fact that it reaches outside the scope of the project and into 
> the way a person speaks or behaves on their own time, and it uses the project 
> maintainer’s own understanding of the project’s ethical values as a basis for 
> determining bad behavior. Everything in the project, nothing outside the 
> project…

I know Paul too, and while I really like him as a person and find his company 
most enjoyable (with or without drinks and good steak!) I usually disagree with 
his political views because I think they're overly simplistic or maybe even 
naive, and I think his generous utilization of the word "fascism" during this 
discussion is not helping because it escalate(d/s) the rhetoric at a way too 
early point in time and cause(d/s) division when unity was/is needed.

However, I very much appreciate how persistently and passionately he is 
participating in this debate, especially because I share many of his concerns.

David


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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 06.01.2016, at 07:21, Anthony Ferrara  wrote:
> 
> Stas,
> 
> I wanted to avoid citing personal examples for personal reasons. But
> since you refuse to read between the lines, here it goes:
> 
> I have received no less than 4 direct threats of violence that were
> directly due to my involvement with the Scalar Type Declarations RFC.
> 
> I believe that both Zeev and myself crossed significant lines during
> that discussion as well, to which there should have been some level of
> recourse or moderator that could have stepped in to cool us down and
> help.

But do you think a CoC could or should have intervened here? Simply because two 
grown-up human beings couldn't agree on something and found it difficult to 
take a step back when the argument became to heated?

More to the point, where is that line crossed? Are you confident that Zeev and 
you both think that lines were crossed, and would you mark those lines at the 
same moments during the debate?



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 08.01.2016, at 07:09, Anthony Ferrara  wrote:
> 
> I think if the current RFC went to vote, it would come very close to
> passing as-is. But as I've said before, I don't think it's anywhere
> near ready to vote on. Larry has started a discussion with the people
> behind Drupal's CoC, and I hope that leads to significant change and
> clarity in the CoC and CRP that I'm proposing.

I'd like it if we didn't even begin to consider this line of argument ("it 
would probably already pass"), and I'm glad that we're remaining open to debate 
here (and it should kept open for much, much longer).

If this aims to be a ~democratic process, then the approach cannot simply be 
"enough people are in agreement, done". An essential goal of a democracy or a 
process that attempts to emulate/imitate is not to simply assert the interests 
of the majority, but protect the interests of the minorities - or, in this 
case, those in opposition.



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 08.01.2016, at 07:47, Anthony Ferrara  wrote:
> 
> I don't think anything in this thread warrants the term "attack" or
> "harassment". While I strongly don't agree with the tone being used
> nor the tactics being used, I don't think they warrant any sort of CoC
> violation.

But who gets to decide that for future instances of... let's call them "heated 
debates"? The person who feels offended in some way, or merely disagrees?

This sheer subjectivity IMO is the biggest issue here.


> Sure. I'm sure there are a lot more that aren't talking that are
> against it. But I think you proved my point here which is that people
> are afraid to share their opinion here. That is a strong indicator
> that something isn't healthy *today*. It says nothing about the
> potential solution, but it should act as a pretty strong heuristic
> that "status quo" isn't really good either.

I was not hesitant (or, let's maybe call it "intentionally procrastinating") to 
post on this topic because I felt unsafe on this list or in the general realm 
of the PHP community; I simply was in no mood to deal with a mob of 
self-proclaimed-or-not "Social Justice Warriors" and their digital pitchforks 
on twitter or elsewhere - and they're already trying: 
https://twitter.com/drupliconissad/status/685489458934841344



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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[David Zuelke]

On 06.01.2016, at 12:31, Rowan Collins  wrote:
> 
> On 6 January 2016 19:42:29 GMT, Stanislav Malyshev  
> wrote:
>> I love it how The Law spends so much text and yet leaves so much
>> unspecified and open to interpretation.
> 
> Welcome to Common Law. Defining the details is basically the job of judges, 
> applying the intent of the law to individual cases as they come up. This 
> generally turns out to be better than trying to codify every possible 
> scenario in advance and leaving loopholes - as long as you trust your 
> judiciary!

That works for the Common Law, because professionals with specialized education 
and training do this, but it does not work for a CoC, where a bunch of 
well-intentioned amateurs (and no, that's not intended to be offensive, but an 
objective observation; it's quite sad that I have to point that out) are 
expected to perform the ruling that allows "the law" to evolve.



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

Re: [PHP-DEV] Practical comparisons on PHP7

[David Zuelke]

Lester, we are software developers. not fortune tellers.

Stop speculating. Gather data. Profile your stuff and look where the 
bottlenecks are. 


> On 10.12.2015, at 12:16, Lester Caine  wrote:
> 
> On 10/12/15 11:02, Björn Larsson wrote:
>> Just noticed that Smarty team is working on a 3.1.28 relase that plans
>> to be PHP 7 compliant, see: https://github.com/smarty-php/smarty
> 
> The version I'm running is not giving any errors, similarly ADOdb. Both
> were brought up to be clean on PHP5.4 and that seems to be the case with
> most BC problems. BUT should either of these packages need any 'major
> upgrade' to take advantage of a faster PHP7? They are e_strict compliant
> and well structured so why would they not perform twice as fast on PHP7?
> 
> -- 
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] Practical comparisons on PHP7

[David Zuelke]

Then do a trace with xhprof/xdebug/blackfire and see where the time is spent. 
How should we magically know the answers?

> On 09.12.2015, at 20:02, Lester Caine  wrote:
> 
> On 09/12/15 16:24, Rowan Collins wrote:
>>> So as somebody already said, maybe your code or setup is really busted.
>> 
>> Really busted, or spending all its time in a type of operation that ZE3
>> can't particularly optimize...
> 
> But I'd like to understand why what is fairly simple PHP code is
> apparently not working as some of you seem to expect. Much of the
> original code goes back to PHP4 days and has been optimised and updated
> over the years and re-factored a couple of times. It's doing the jobs
> required and giving response times that clients are happy with in the
> sub second on intranets. The only PHP7 fixes so far is a few __construct
> changes from the original named constructor ... the rest of the code is
> already e_strict clean.
> 
> So where should I be looking to work out why PHP7 seems little better
> than PHP5. This code is ADOdb and Smarty based with templates which have
> developed over 10+ years and we can switch on page caching for the
> static material, but many sites are running with dynamic data such as
> calling clients from queues and displaying dynamic information pages.
> 
> -- 
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

[David Zuelke]

See my suggestion to split it into two separate votes ;)

> On 08.12.2015, at 17:11, Derick Rethans  wrote:
> 
> On Tue, 8 Dec 2015, Zeev Suraski wrote:
> 
>> Following the initial discussion, I prepared an RFC that proposes to extend
>> the support periods for PHP 5.6:
>> 
>> https://wiki.php.net/rfc/php56timeline
>> 
>> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
>> omissions.
>> 
>> Let the discussion continue…
> 
> I think you're making the voting too complicated :-) In the case that I 
> don't want to extend it, I can only pick "no"... but can I still make a 
> preference for +1 or +2 years? I don't really know... 
> Better make it a three way choice, where you just tally up the two 
> "extend please" votes to be over 50%?
> 
> cheers,
> Derick
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline

[David Zuelke]

It just occurred to me (too late :D sorry Zeev) that it might make sense to 
split this into two RFCs:

- to define the active support end date for 5.6 (e.g. "2016-08-28" or 
"2016-12-02" or "2016-12-31")
- to define the security support end date for 5.6, and specify that relative to 
the active support end date only (e.g. "12 months after active support end 
date" or "24 months after active support end date")

That would also allow us to, if the need arises, change the active support end 
date sometime next year (for whatever reason; let's hope it is not necessary!) 
without having to open up a discussion about the security end date again ;)



> On 08.12.2015, at 16:14, Zeev Suraski  wrote:
> 
> Following the initial discussion, I prepared an RFC that proposes to extend
> the support periods for PHP 5.6:
> 
> 
> 
> https://wiki.php.net/rfc/php56timeline
> 
> 
> 
> Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
> omissions.
> 
> 
> 
> Let the discussion continue…
> 
> 
> 
> Zeev


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

Re: [PHP-DEV] Practical comparisons on PHP7

[David Zuelke]

On 08.12.2015, at 13:32, Lester Caine  wrote:

> Bottom line is that given the real world loading on my sites, the
> differences are probably in the noise of network transit times so not
> impressive at all :(

... or you have a bunch of very slow queries in there that are eating up the 
majority of request time regardless of PHP version.

Sorry, Lester, but what you're posting here indicates that the experiment 
you're running is not very well designed and contains a lot of unknown 
variances between your setups. Please fix that and run some properly set up to 
get genuinely comparable results.

P.S. Why do you even still run eaccelerator in the year 2015!?


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

Re: [PHP-DEV] PHP 5.6 life cycle

[David Zuelke]

On 06.12.2015, at 20:38, Anatol Belski  wrote:

> From today's perspective, I'd suggest to extend the security only period of 
> 5.6.

That would be my suggestion too.

End "full" support in, say, December 2016 (a year after 7.0.0), but then give 
it two years of security fixes instead of just one.



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

Re: [PHP-DEV] 7.0.0 release

[David Zuelke]

On 24.11.2015, at 12:57, Leigh  wrote:

> I prefer a over c.
> 
> As you said, we can deliver a stable and high quality 7.0.0 today. An RC
> period where you expect no bugs does not sound productive to me.

That is exactly the point of an RC. No show-stoppers means you then roll the RC 
out as the golden version. Otherwise, another RC. Rinse and repeat.



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

Re: [PHP-DEV] 7.0.0 release

[David Zuelke]

On 23.11.2015, at 22:10, Anatol Belski  wrote:

> So in the end, a solution is wanted. I don't think any opinion is allowed to 
> be ignored for such a topic. So options
> 
> a) release on 26th including all known bug fixes
> b) do RC8, assume there are no bugs, so target 10th for RTM
> c) do RC8, release on 3rd, expect there are no bugs come in
> d) continue issuing release candidates till it's stable enough (needs 
> definition of stable and probably an RFC)
> 
> I would really ask to reach a consent on either a) or c). IMO, the options b) 
> and d) are the direct road to curbing 7.0.0.  There is no hurry to release 
> just to release, but it is definitely harmful to slow down the rise.

My vote (if it matters) goes for c)

It also has the nice side effect of not clashing with ~Black Friday, and by 
next week, the "oh wow Wordpress just moved to Node.js" hype will have died 
down too, giving PHP 7 more of the attention it deserves ;)



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

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[David Zuelke]

On 23.11.2015, at 04:02, Rasmus Lerdorf  wrote:
> 
> On Nov 23, 2015, at 00:48, Adam Harvey  wrote:
>> 
>> Here's an alternative suggestion: we've previously switched to one
>> week RC cycles late in the piece when trying to get major releases
>> stabilised and we're at the point of only fixing one or two things per
>> RC. That's exactly where we are now. Why don't we do that again —
>> release a fix for this bug as an RC 8 this week, and then do a release
>> on December 3 if nothing else significant comes up?
> 
> Still not entirely convinced this bug is major enough to warrant the
> delay. It seems right on the edge to me. But since it is on the edge
> there will be enough people who think it is major that we probably
> should wait on it. Doing a one-week RC8 this week and aiming for
> a Dec.3 release seems like a good solution to me.

That sounds like a good compromise indeed!



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

Re: [PHP-DEV] PHP7 / foreach / references / ugly code / discrepancy to PHP 5.6

[David Zuelke]

Should this be in the UPGRADING notes?


> On 10.11.2015, at 20:45, Nikita Popov  wrote:
> 
> On Tue, Nov 10, 2015 at 5:48 PM, Philip Hofstetter <
> phofstet...@sensational.ch> wrote:
> 
>> Hi,
>> 
>> I'm having a cause of slightly ugly code that runs differently from PHP 5.6
>> to PHP 7 and I don't think this difference is documented, nor expected. As
>> I'm not sure whether this is an intended change or not, I'm asking here
>> firstr before making a bug report.
>> 
>> The code in question is
>> 
>> 
>> $b = [1, 2, 3];
>> 
>> foreach($b ?: [] as &$v){
>>$v = $v*2;
>>unset($v);
>> }
>> 
>> var_dump($b);
>> 
>> in PHP7, this produces
>> 
>> array(3) {
>>  [0] =>
>>  int(1)
>>  [1] =>
>>  int(2)
>>  [2] =>
>>  int(3)
>> }
>> 
>> whereas in PHP 5.6 and earlier, this produces
>> 
>> array(3) {
>>  [0] =>
>>  int(2)
>>  [1] =>
>>  int(4)
>>  [2] =>
>>  int(6)
>> }
>> 
>> what scares me about this is that in order to get the old behaviour in PHP7
>> back, you just have to get rid of the ?: operator:
>> 
>> foreach($b as &$v){
>> 
>> is fine
>> 
>> foreach($b ?: [] as &$v){
>> 
>> is not.
>> 
>> I guess this is related to
>> 
>> http://php.net/manual/en/migration70.incompatible.php#migration70.incompatible.foreach.by-value
>> or
>> 
>> http://php.net/manual/en/migration70.incompatible.php#migration70.incompatible.foreach.by-ref
>> ,
>> but I'm not entirely sure whether this is actually intended behaviour -
>> it's certainly unexpected to me that applying ?: now always makes a copy
>> whereas before it didn't.
>> 
> 
> This is a bug in PHP 5, which has been fixed in PHP 7 as a side-effect of
> other changes. The new behavior is correct. This issue is tracked at
> https://bugs.php.net/bug.php?id=70857.
> 
> Nikita


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

Re: [PHP-DEV] PHP 7 RTM date

[David Zuelke]

On 10.11.2015, at 10:26, Lester Caine  wrote:
> 
> On 10/11/15 00:49, Rasmus Lerdorf wrote:
>>> November 30 is Cyber Monday, where people are either
 
 a) focused on maxing out their credit cards on every possible e-commerce 
 site, or
 b) unable to roll out PHP 7 because their customers are busy with a)
 
 At least at Heroku we have a blackout policy around Thanksgiving and 
 Christmas for platform changes, and I'd imagine other hosting platforms do 
 as well.
 
 So maybe either Tuesday, or even better, Thursday, since that's release 
 day anyway.
>> Let's be realistic. This is not a critical security fix for production
>> servers. This is a .0.0 release. For developers this marks the point
>> where they need to start making upgrade plans if they haven't already. I
>> realize for Heroku and the few similar cloud computing services out
>> there it might be slightly different in that you want to be quick to
>> provide the first golden PHP 7 to your customers.
>> 
>> My only concern with the timing is whether we are adding undue
>> inconvenience to our RM team and all the other folks on our side that
>> are affected by a release.
> 
> Anybody moving their current stable infrastructure to PHP7 without fully
> testing deserves everything they get? PHP7 should be 'rolled out' as a
> secondary option for savy users who understand the implications since
> the code base WILL need to be reworked before it becomes a stable
> replacement for the current PhP5.x infrastructure. Actually a cloud
> service getting something out as a taster for PHP7 before the holiday
> could only be helpful since it would give more eyes on real world
> migration problems in much the same way that PHP5 roll-out was probably
> helped by RC's being available on some hosting services back then. ARE
> any cloud services providing that facility today with PHP7 RC's?

Sure: http://phpversions.info/paas-hosting/

The default PHP version in the absence of any explicit declaration on Heroku 
will remain 5.6.latest for a while, but if you have a composer.json with a 
bunch of requirements for package "php" like ">=5.3.3", and not a single one 
with an upper bound, then on the day we make PHP 7.0.0 available, your next 
deploy will get PHP 7, because your composer.json says that's fine (unless you 
also require extensions that are not PHP 7 ready; it all gets resolved 
correctly).

Of course, I'll roll out a warning soon to remind users of this, but many will 
miss it because they tend to never read what's on their screens, so the more 
stable 7.0.0 is, the better!

You'd be surprised how many of our users have composer.json templates from 
weirdo frameworks with "minimum-stability": "dev", and they don't even notice 
that they're getting PHP 7 RCs because of that.

David



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

Re: [PHP-DEV] PHP 7 RTM date

[David Zuelke]

November 30 is Cyber Monday, where people are either

a) focused on maxing out their credit cards on every possible e-commerce site, 
or
b) unable to roll out PHP 7 because their customers are busy with a)

At least at Heroku we have a blackout policy around Thanksgiving and Christmas 
for platform changes, and I'd imagine other hosting platforms do as well.

So maybe either Tuesday, or even better, Thursday, since that's release day 
anyway.


> On 09.11.2015, at 20:50, Andi Gutmans  wrote:
> 
>> On Nov 8, 2015, at 5:35 PM, Rasmus Lerdorf  wrote:
>> 
>> On 11/08/2015 05:16 PM, Anatol Belski wrote:
>>> Exactly, the relevant patches are going into RC7 which is then out on 12th
>>> instead of GA. The next closest release slot were then Nov 26th, either for
>>> GA or for RC8 (but better not try to predict). If it stands good, we might
>>> have no reason to wait until the Mrs. Lovelace birthday party :)
>> 
>> We should try really hard to get it out on the 26th. Once we get into
>> December people start to disappear. Nov.26 is American Thanksgiving
>> though, but I don't think that should interfere.
> 
> I think thanksgiving is not a great time to releasing something so 
> significant. Most folks in the US are on time off and you won’t get as much 
> interest.
> 
> If we do need to postpone I’d aim for Nov 30th or Dec 1st then. My experience 
> is that as long as you’re in the first two weeks of December you still get 
> people. After the 14th you slow down….
> 
> I know we are open-source and release when it’s ready but I think for such a 
> huge deal it is worth waiting three more working days. 
> 
> Btw, do we want to do something special on php.net ? Front 
> page?  Not the sexiest site as-is so maybe gives us an excuse to spice up the 
> front page?
> 
> Just my 2 cents.
> Andi


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

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[David Zuelke]

On 06.10.2015, at 19:28, Pierre Joye  wrote:

> The license cannot be changed without approvals of every contributor
> to date. I very much doubt they will. And to make that point clear for
> me, if they do and come with anything but the PHP license, I can
> already say that I won't accept it.

First, a license change may be necessary from their side in case "Zend 
Technologies Ltd" ceases to exist.

Second, never say never. The PHP and Zend licenses are just BSD licenses with a 
few more or less irrelevant (to the code, the project, and its future) 
additional sections about the use of the word "PHP" in product names and that 
you must under no circumstance feed an Elephpant spinach on the last Friday of 
the month or something like that.

So a switch to "pure" BSD, for example, probably wouldn't be a big deal, even 
to you, would it?

David



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

Re: [PHP-DEV] PCRE JIT stack size limit

[David Zuelke]

On 24.07.2015, at 09:33, Adam Harvey  wrote:
> 
> On 23 July 2015 at 11:47, Christoph Becker  wrote:
> 
>> Therefore I tend to prefer a new ini setting (say, pcre.jitstack_limit).
>> That would mean, however, to add yet another ini setting, of which
>> there are already so many.
> 
> I'm not a big fan of that, although it's at least in the spirit of
> what configuration settings are meant to be used for.
> 
> What if we added the PCRE_ERROR_JIT_STACKLIMIT error constant to those
> exposed to userland so that it's more easily noticed via
> preg_last_error(), and adding a modifier that can be used to disable
> the JIT on a per-pattern basis (by setting PCRE_NO_START_OPTIMIZE,
> which admittedly disables other stuff too, but at least the regex will
> run)? At least then users could check the error when the regex fails
> and re-run the regex without the JIT if they chose to.

But this might mean that patterns which previously worked, because no JIT was 
used, suddenly fail in existing code with a new error constant. Which I guess 
is a BC break.



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

Re: [PHP-DEV] Fixing bundled extension version mess

[David Zuelke]

Since I'm working on something related... what's the verdict here? :)



> On 20.04.2015, at 20:00, Jakub Zelenka  wrote:
> 
> Hi,
> 
> On Thu, Apr 16, 2015 at 1:21 PM, Pierre Joye  wrote:
> 
>> On Thu, Apr 16, 2015 at 6:27 PM, François Laupretre 
>> wrote:
 De : Pierre Joye [mailto:pierre@gmail.com]
 
 The problem we have now is core extensions with senseless versions
 without
 any external versions. Or mixed codebase, like core is a mix of external
 and core specific codes which is not in any external releases. That is
>> what
 we should solve.
>>> 
>>> Do you have a list of these problematic extensions ?
>> 
>> json : 1.2.1
>> 
> 
> I bumped json to 1.4.0  some time ago and I would like to have its own
> version as well. The reason is that after releasing PHP 7 I plan to release
> jsond pecl ext for PHP 5 that will be drop in alternative for the existing
> json in 5 and will behave exactly as json in 7. They will both have the
> same major and minor. It will be also useful for other things to maintain
> that versioning.
> 
> Cheers
> 
> Jakub


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

Re: [PHP-DEV] Branching off PHP7 and electing RMs

[David Zuelke]

But an alpha timeline sounds good ;)


> On 13.05.2015, at 16:32, Pierre Joye  wrote:
> 
> On May 13, 2015 7:57 PM, "Julien Pauli"  wrote:
>> 
>> Hello people.
>> 
>> Time is going, and summer is coming.
>> 
>> I think we must have branched 7.0 until end of May, and have our 2 RMs
>> elected.
>> 
>> Don't forget we are starting a long testing process, and some people start
>> having some PRs to target 7.1, so we need to branch.
>> 
>> The plans are to branch so that we prevent any not-wanted merge, and focus
>> on stabilization.
>> Start a calendar about our first alpha as well.
>> 
>> If we want 7.0 to be released around October/November , we need to handle
>> those tasks right now.
>> 
>> Thoughts ? ;-)
> 
> I think it is safe to keep master for now. Easier as there is still quite
> some work. Tyrael and Anatol will have less merging work.
> 
> Cheers,
> Pierre
> 
>> Julien.Pauli


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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[David Zuelke]

I feel like this one is different though, because there already was consensus 
that the current naming isn't the best, and there was support for Throwable, 
while voting on the "original" RFC was still open.

To adhere to the RFC process, the open RFC wasn't changed accordingly, because 
voting was already underway.

And then we collectively dropped the ball when it came to remembering to do 
this little Throwable proposal and change.

Think of it more as just a few renames to fix engine exceptions before they go 
out.

David

P.S. *bump* by the way ;)


> On 30.04.2015, at 18:51, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> We could make an exception (sic !) and add the Throwable interface to PHP7,
>> even after feature freeze, because it is an easy pick and having a clear
>> Exception model for 7.0 is to my opinion very important.
> 
> I'm OK with it but I fear this is opening a can of worms, since people
> will start arguing "well, we've added Throwable so let's also add this
> other thing which is absolutely 100% necessary" and here goes our
> feature freeze. Maybe I'm just too cynical :) Anyway, I don't have any
> objection on substance to it. So if everybody is ok with it, I'm fine
> with it too.
> -- 
> Stas Malyshev
> smalys...@gmail.com
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[David Zuelke]

Why not wait with the merge until a consensus emerges regarding Throwable?


> On 09.03.2015, at 05:26, Nikita Popov  wrote:
> 
> On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov  wrote:
> 
>> Hi internals!
>> 
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and recoverable fatal errors into exceptions, has opened:
>> 
>>https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
>> 
>> The primary vote requires a 2/3 majority, as this is a language change.
>> 
>> A second vote will decide whether to use a BaseException based inheritance
>> hierarchy. This vote uses a simple majority.
>> 
>> Voting is open until 2015-03-08.
>> 
> 
> This RFC has been accepted with 60 votes in favor and 2 against. The
> BaseException hierarchy has been accepted with 39 in favor and 19 against.
> 
> During voting some concerns about the naming of the BaseException class
> have been raised. This detail can be sorted out in a follow-up discussion -
> changing this (assuming only the name is changed) is simple and only a
> couple of tests need to be adjusted.
> 
> Dmitry, do you want to merge your current patch?
> 
> Nikita


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

Re: [PHP-DEV] [VOTE] Exceptions in the engine

[David Zuelke]

+1000 on this; so much better than the BaseException stuff!


> On 27.02.2015, at 15:31, Sebastian Bergmann  wrote:
> 
> Am 23.02.2015 um 19:15 schrieb Nikita Popov:
>> Voting on the engine exceptions RFC, which proposes to convert existing
>> fatal and recoverable fatal errors into exceptions, has opened:
>> 
>>https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
>> 
>> The primary vote requires a 2/3 majority, as this is a language change.
>> 
>> A second vote will decide whether to use a BaseException based inheritance
>> hierarchy. This vote uses a simple majority.
> 
> I have voted yes on "Allow exceptions in the engine and conversion of
> existing fatals?" and no on "Introduce and use BaseException?" and
> would like to elaborate on the latter.
> 
> I am sorry that I was unable to raise this concern earlier (did not
> really become aware of the RFC before it was put to the vote), but I
> would prefer the following:
> 
>   * Introduce a Throwable interface
>   * Let Exception implement the Throwable interface
>   * Introduce an Error class that implements the Throwable interface
>   * Use Error class as base class for exceptions raised by the engine
> 
> This would be along the lines of what Java does.
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] Allow "tightening" of PHP_INI_SYSTEM directives in PHP_INI_PERDIR+ contexts?

[David Zuelke]

Hi,

Currently, some directives such as "expose_php" or "allow_url_fopen" can only 
be changed on the PHP_INI_SYSTEM level, which in some cases apparently even 
means through php.ini only.

Wouldn't it make sense to allow "tightening" of these values in, say, a PERDIR 
contexts? So "expose_php" can be disabled in an FPM config, but not enabled?

This would, I think, be useful for several directives that could then be set to 
a "safer" setting on a per-dir basis, such as:

- expose_php
- allow_url_fopen
- allow_url_includes (if set to "1" in system)
- disable_functions/classes (only additions to the list allowed)

Thoughts?

David



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

Re: [PHP-DEV] Faster zend sorting implementation

[David Zuelke]

On 06.01.2015, at 05:42, Pierre Joye  wrote:

> I am not sure about that. Introducing a not easy to catch BC break for
> 0.1% gain on function (or even for the whole app) is not very
> appealing.
> 
> However, there is nothing in the documentation actually describing how
> it works and there are clear warnings about the unpredictable results.
> That means we won't actually break it,per definition. I only wonder if
> it is worth the effort for such little gain (yes, the ocean is made of
> drops ;).

The clear benefit I see is that it turns it into a stable sort, although we 
could of course always break that again in the future unless we explicitly 
specify/guarantee it to be stable from now on (without any other guarantees 
about the algorithm).



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

Re: [PHP-DEV] Faster zend sorting implementation

[David Zuelke]

This sounds reasonable, because given how the sort is *not* stable, there will 
be other cases (totally made up, but let's say ["a", "o", "O"]) where the swap 
does *not* happen. Consistency, and thus a stable sort, is better.

But you're saying your patch is "kind of a" stable sorting algo, so is it 
stable only sometimes, or did you mean to say "a kind of"?

David


> On 05.01.2015, at 18:08, Xinchen Hui  wrote:
> 
> Hey:
> 
> I was working on zend_qsort improvement. but I got a problem need
> to be disscussed with you fist..
> 
> as we know,  previously zend_qsort is not a stable sorting algo.
> 
> my draft patch (which already get 0.1% IRs reduce in wordpress)
> is kindof a stable sorting algo, you can find it here
> (https://github.com/laruence/php-src/compare/zend_sort)
> 
> so, there is a bc break, like for :
> 
> $array = array("o",  "O");
> sort($array, SORT_STRING|SORT_FLAG_CASE);
> 
> var_dump($array);
> 
> previously implementation does the swap:
> 
> array(2) {
>  [0]=>
>  string(1) "O"
>  [1]=>
>  string(1) "o"
> }
> 
> but new implementation doesn't not:
> 
> array(2) {
>  [0]=>
>  string(1) "o"
>  [1]=>
>  string(1) "O"
> }
> 
>do you think such BC break is acceptable? or I still need a RFC? :<
> 
> thanks
> -- 
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] PHP-FPM state

[David Zuelke]

Well, there are two changes there (not sure why "move zlog_set_level() again 
shows up twice in the log"?)

One changes the pm.start_servers calculated default message to a notice (makes 
total sense IMO).

The other moves zlog_set_level() so it's called earlier, or else the log level 
isn't set yet at the moment the notice/warning above is issued.

You did merge the very similar other PR (894) to 5.5, where zlog_set_level() 
was already moved to an earlier stage to fix a similar issue (where messages 
like "user ignored when not running as root" would be emitted regardless of 
log_level).

So in the interest of behavioral consistency between the two versions, I'd say 
merge at least the zlog_set_level() move, but the pm.start_servers change is 
not comparable to the IPv6 breakage because it doesn't change any logic, and we 
now have tests in 5.6.

David


On 20.11.2014, at 10:34, Remi Collet  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I think the situation is now better.
> 
> At least test suite grow from 3 to 15 tests (+1 for Apparmor)
> and all recent bugs / changes are covered.
> 
> Notice: test suite is 5.6+ only as rely on --force-stderr
> 
> 
> Some minor changes are 5.6+ only
> 
> 09f9f7ce5030973052bca5043425bd9f20ad7a7e move zlog_set_level() again
> 7e0ccb6d1217b6738117ab19590444fec9d0951a warning to notice
> 909d44f20dd00ccf3a6519707bfaba2ed30e8b2b move zlog_set_level() again
> 914787491d78cded722318d0796b13f11cb197f8 warning when multiple addr
> 
> I was asked (by the author of the 3 firsts) to also apply them in 5.5
> 
> What do you think ?
> 
> I'm a bit relunctant, because we already have so much changes...
> but in all cases we'll need a big test/QA for FPM in 5.5.20 / 5.6.4.
> 
> 
> Remi.
> 
> P.S. Still TODO: listen_allowed_clients is now aware of IPv4/IPv6, but
> it could make sense to make it aware of hostname (using getaddrinfo),
> and set all found addresses as allowed. Probably not urgent.
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlRttbEACgkQYUppBSnxahgzFwCeM7YJQ+G07RtZSyn1vtH0QOn3
> XxIAniVlKn1YhGFMT6bWq3RojOeYSr0K
> =tULN
> -END PGP SIGNATURE-
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken

[David Zuelke]

On 05.09.2014, at 10:54, Remi Collet  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Le 05/09/2014 15:52, David Zuelke a écrit :
> 
>> People should simply use the SetHandler approach instead.
> 
> I agree, see https://bugzilla.redhat.com/1136290
> 
> But some people may want to use ProxyPass (ex, to redirect to another
> server, with no PHP script installed locally).

You can do that just fine with SetHandler; the FastCGI server doesn't have to 
be on the same box.

David


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

Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken

[David Zuelke]

The fix is not broken. He's describing a different/additional issue. Things 
have always been shaky with ProxyPass (that's 
https://bugs.php.net/bug.php?id=65641) because it's a bag of hurt. That's the 
whole reason Apache now has SetHandler for proxies!


On 08.09.2014, at 22:54, Stas Malyshev  wrote:

> Hi!
> 
> So what is the resolution for this? Should we roll back the fix,
> implement the new one and have one more RC, do something else?
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken

[David Zuelke]

The fixes in that ticket were pretty risky as they very late in the game 
fiddled with strings. That was brittle should have been fixed earlier during 
request processing.

The new patch 
(https://bugs.php.net/patch-display.php?bug=65641&patch=Another_fix_for_mod_proxy_fcgi.patch&revision=1409922889)
 looks better, but doesn't account for cases where SCRIPT_NAME Is correct (not 
sure if that can be checked), and I don't understand why env_script_name is 
restored back to its original value after writing it to SCRIPT_NAME. At the 
very least, the comment in that if should say "this is for ProxyPass and 
SCRIPT_NAME being broken with index.php/foo".

But that doesn't matter anyway, because ProxyPass is a bag of hurt for a 
million and one reasons. Rewrites are not applied, you can't check if the file 
exists et cetera.

People should simply use the SetHandler approach instead. If your version of 
Apache 2.4 doesn't have that yet, use 
https://gist.github.com/progandy/6ed4eeea60f6277c3e39

David

P.S.: if you also want to check if the .php file exists:

  # make sure the file exists so that if not, 
Apache will show its 404 page and not FPM
   SetHandler "proxy:fcgi://127.0.0.1:9003"
 


P.P.S.: as a reminder, if you want to use UDS:

 disablereuse off # any parameter in here will do so the proxy is registered 
during startup and can be referenced later as "fcgi://php"


 
   SetHandler "proxy:fcgi://php"
 


On 05.09.2014, at 05:54, Philip Hofstetter  wrote:

> On Fri, Sep 5, 2014 at 1:18 PM, Remi Collet  wrote:
> 
>> 2. ProxyPass Configuration
>> 
>>ProxyPass /proxy/ fcgi://127.0.0.1:9003//var/www/html/
>> 
>> URL = /proxy/info.php/a/b?q=a
>> SCRIPT_NAME = /proxy/info.php/a/b
>> => Broken
> 
> This is bugging me too on my development machine where I'm stuck at
> Apache 2.4.9 which doesn't yet have support for using SetHandler this
> way.
> 
> Applying the patch fpm_main-script_name-v2.patch  proposed on
> https://bugs.php.net/bug.php?id=65641 fixes the issue for me.
> 
> This is happening for me with PHP 5.4, 5.5 and 5.6 (which are the ones
> I tested).
> 
> Philip
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] 5.4 security only

[David Zuelke]

I'd like to see https://github.com/php/php-src/pull/694 / 
https://github.com/php/php-src/pull/765 in so FPM in 5.4 will work properly 
with Apache 2.4.10+'s mod_proxy_fcgi.

David


On 19 Aug 2014, at 01:59, Stas Malyshev  wrote:

> Hi!
> 
> Moving this out of other topics into its own: according to the release
> RFC, we should have 5.4 have 2 years of bugfixes & one year of security
> fixes. Since 5.4 was released in March 2012, we're already past 2 year
> mark. However, we're still have some bugfixes in 5.4, so I'd like to do
> this:
> 
> - 5.4.32 is released as planned this week, nothing changes there.
> 
> - 5.4 branch that is to be 5.4.33 will be the last release that has any
> non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is
> out too, so that would play nice with the "two stable branches, one
> security branch" theme. Starting from that release forward, 5.4 would be
> purely security fixes only branch.
> 
> - EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into
> 5.4 branch unless they are very important ones (and that is only because
> people may, in theory, have pending patches and we didn't give advance
> notice). Importance would have to be determined somewhat arbitrarily,
> but basically if it works without it, then it's not in, if there's
> serious doubt if it should be in, it's not in, etc. Security issues, of
> course, still allowed in.
> 
> This means if somebody has some pending non-security fixes that have to
> be in 5.4, the following two weeks are the last call, provided that the
> fixes really must be in 5.4.
> 
> Any objections/suggested modifications to this plan?
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] Native support - PUT request, multipart form data

[David Zuelke]

On 17 Aug 2014, at 22:55, Chris Wright  wrote:

> On 17 August 2014 11:49, David Zuelke  wrote:
>> That does not make any sense; applications could accept XML, CSV or whatever 
>> else just as well.
>> 
>> The original proposal is not very useful. $_GET contains parsed query string 
>> info, $_POST contains parsed HTTP request body information if the media type 
>> is application/x-www-urlencoded or multipart/form-data. Deserializing that 
>> makes sense as the rules for it are in the HTTP spec.
> 
> (warning: nitpicking) actually, neither of these types are part of the
> HTTP specification, the protocol specification doesn't deal with how
> to handle content, only how to transmit it. RFC 2616 makes no mention
> of it, and RFCs 7230-7235 don't either.

Sorry, typo, I meant to write HTML.


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

Re: [PHP-DEV] Native support - PUT request, multipart form data

[David Zuelke]

That does not make any sense; applications could accept XML, CSV or whatever 
else just as well.

The original proposal is not very useful. $_GET contains parsed query string 
info, $_POST contains parsed HTTP request body information if the media type is 
application/x-www-urlencoded or multipart/form-data. Deserializing that makes 
sense as the rules for it are in the HTTP spec.

$_PUT/$_BODY/$_DATA would then have to contain the raw body contents, at least 
if the media type isn't one of the above, for consistency. That'd saves the 
file_get_contents() call, and given how a request handler uses at most once, 
I'm not sure such a change is worth it.

David


On 17 Aug 2014, at 04:18, Thomas Bley  wrote:

> Since we get JSON data, I would also consider $_JSON.
> 
> Regards
> Thomas
> 
> 
> Park Framework wrote on 17.08.2014 01:47:
> 
>> Variable $_PUT is already a popular name.
>> Many for yourself already so it was called, at the bottom link.
>> http://stackoverflow.com/search?q=PHP+%24_PUT
>> 
>> But I like the name $_DATA - it is universal for any request method.
>> For frontend developers, this name is very clear:
>> $.ajax({
>>   type: "PUT",
>>   contentType: "application/json",
>>   data: {"name": "value"}
>> });
>> 
>> Except multipart form data, needed and native support for application/json.
>> 
>> In many languages (Java, Python, ASP), it has long been there.
>> It is a pity that the PHP in 2014, it has not yet implemented.
>> 
>> 
>> 
>> 2014-08-17 2:14 GMT+03:00 Chris Wright :
>> 
>>> On 16 August 2014 23:41, Park Framework  wrote:
 This is necessary for convenient use RESTful API.
 
 file_get_contents('php://input')  - Very inconvenient
 
 I would like to finally get native support for PHP, preferably version
>>> 5.6
>>> 
>>> The window for getting new features into 5.6 has passed, quite a long time
>>> ago.
>>> 
>>> Also, there is no $_PUT superglobal (and personally I do not think
>>> there should be one), and it would not make sense to put this data
>>> into $_POST (or any existing superglobal). Please explain the API you
>>> envisage to get this working.
>>> 
>> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] Re: 5.3 final release

[David Zuelke]

On 22 Jul 2014, at 21:10, Stas Malyshev  wrote:

> Hi!
> 
>> not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
> 
> This is worrying. Looks like the patch is not as safe as we've hoped,
> and causes BC issues for mod_fastcgi, so maybe we should not get it into
> 5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better
> safe than sorry.

I’ll be working on a fix this week. If you can wait a few days, that’d be 
grand; if not, then no biggie.

David


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