Re: [PHP-DEV] php.net website

2017-07-21 Thread Mathias Grimm 
If php is mainly static it could be almost fully cached in a CDN.
For the downloads I don't think the latency would be a problem but that can
also be in the CDN
If php owned two servers in US and two in Europe and possibly 2 in Asia we
would be goon in terms of latency for the search IMO.




On 20 July 2017 at 19:38, Rasmus Lerdorf  wrote:

> On Thu, Jul 20, 2017 at 1:42 AM, Niklas Keller  wrote:
>>
>> They can also just request them themselves, but only for their mirror
>> domain. If you allow them to issue for www.php.net, you can as well just
>> put the current private key there.
>>
>
> I think there is a big difference between putting the private key there
> and proxying validation for just a www.php.net CN alias. We already have
> a list of known mirrors, so we would make sure to only validate
> www.php.net for those. By validating www.php.net we allow any mirror to
> pretend they are www.php.net and no other *.php.net domain, which is
> exactly what we want.
>
> -Rasmus
>

Re: [PHP-DEV] php.net website

2017-07-21 Thread Tony Marston 
"Niklas Keller"  wrote in message 
news:canuqdcjb9uy8jtmmp43bqaw_9xjnombren1zoqh1lubtfo4...@mail.gmail.com...




On Wed, Jul 19, 2017 at 1:07 PM, Mathias Grimm 
wrote:
> I was briefly asking Sara about it and as she pointed out it is likely 
> a

> big project but I think we can do something about it.
>
One thing I should have mentioned on twitter was:
https://wiki.php.net/web/mirror

That'll get you a locally running web-php instance though it's not
ideal for iterative development against the git repo without some
massaging.

As to the actual hosts: There are (I believe) two hosts actually
administered by @php.net folk: us1.php.net and us2.php.net, others
(AIUI) are run by third parties and not under our control.  The PHP
version on these hosts is, comically, not the lastest-and-greatest.
I'm fairly confident it's not even consistently 7.0+ so whatever you
write needs to take that into account (particularly given the status
of third-party mirrors).



We should really change that and fully move to HTTPS.

Regards, Niklas


Why on earth should you need to use HTTPS for a website that does not deal 
with personal information? Nothing on that website can possibly be classed 
as "sensitive" so what would be the point?


--
Tony Marston


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

Re: [PHP-DEV] php.net website

2017-07-21 Thread Andrey Andreev 
Hi,

On Fri, Jul 21, 2017 at 11:47 AM, Tony Marston  wrote:
>
> Why on earth should you need to use HTTPS for a website that does not deal
> with personal information? Nothing on that website can possibly be classed
> as "sensitive" so what would be the point?
>

Because HTTPS isn't just about encrypting secret data. Ensuring data
integrity, authenticity is just as important.

Cheers,
Andrey.

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

Re: [PHP-DEV] php.net website

2017-07-21 Thread li...@rhsoft.net 



Am 21.07.2017 um 10:47 schrieb Tony Marston:

We should really change that and fully move to HTTPS.

Regards, Niklas


Why on earth should you need to use HTTPS for a website that does not 
deal with personal information? Nothing on that website can possibly be 
classed as "sensitive" so what would be the point?


because in a few months major browsers start with warnings if a 
unencrypted page contains any form not just logins? guess hwat happens 
by the search field on the right top corner?


because HTTPS is also about data integrity?

because currently when you click on the download link and have not 
explicitly called https://secure.php.net/ you land on unencrypted 
download-pages?


because the whole web goes straight to HTTPS?

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

Re: [PHP-DEV] php.net website

2017-07-21 Thread Lester Caine 
On 21/07/17 09:47, Tony Marston wrote:
> Why on earth should you need to use HTTPS for a website that does not
> deal with personal information? Nothing on that website can possibly be
> classed as "sensitive" so what would be the point?

That applies to many of the websites I support yet the likes of Google
and Bing now 'downrate' sites that don't have https and browsers
complain about 'insecure' sites. Add the problems created when you add a
private https area to a 'public' domain name and things get even
messier. That some people even here insist that HTTP should be killed
off seems not to have been thought through at all?

On the website front, the problem I see is that while the MANUAL is a
static site, adding things like the wiki, bug system, pecl/pear
management, and other dynamic areas and allowing a decent CLEAN cross
content search is what I see as being needed. Add managed translations
then while a single static english copy of the main stuff is easy to
distribute, and dynamic set of content WOULD be easier going forward.
Except there would never be any agreement on how THAT would be managed
and on which database engine :(

-- 
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-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread li...@rhsoft.net 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090: 
zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0' failed.


below a backtrace of 'opcache' from 7.2.0 beta1, the used 'php.ini' and 
the start of the build-process with configure and compiler params


i used to build HEAD for a long time with my rpm-spec file by just 
replace the tarball, alpha1 did not compile at all, late rbuild was fine 
as well as our cli-cms-testsuite but the intermediate webserver before 
the second part for a PGO-build was broken


currently 'opcache' when "opcache.enable_cli = 1" is enabled crashs very 
early (before any output line of the application)

_

[builduser@testserver:/rpmbuild/PHP-PGO]$ gdb -ex=r --args 
/home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php -c 
/rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php

GNU gdb (GDB) Fedora 7.12.1-48.fc25
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
/home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php...done.
Starting program: /home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php 
-c /rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 25798.
php: 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090: 
zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0' failed.


Program received signal SIGABRT, Aborted.
0x76d448df in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install 
bzip2-libs-1.0.6-21.fc25.x86_64 cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 
expat-2.2.1-1.fc25.x86_64 fontconfig-2.12.1-1.fc25.x86_64 
freetype-2.6.5-9.fc25.x86_64 gd-2.2.4-1.fc25.x86_64 
glibc-2.24-9.fc25.x86_64 jbigkit-libs-2.1-5.fc24.x86_64 
keyutils-libs-1.5.9-8.fc24.x86_64 krb5-libs-1.14.4-7.fc25.x86_64 
libX11-1.6.5-1.fc25.x86_64 libXau-1.0.8-6.fc24.x86_64 
libXpm-3.5.12-1.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64 
libcrypt-nss-2.24-9.fc25.x86_64 libcurl-7.51.0-7.fc25.x86_64 
libgcc-6.3.1-1.fc25.x86_64 libgomp-6.3.1-1.fc25.x86_64 
libicu-57.1-5.fc25.x86_64 libidn2-2.0.2-1.fc25.x86_64 
libjpeg-turbo-1.5.1-0.fc25.x86_64 libnghttp2-1.13.0-2.fc25.x86_64 
libpng-1.6.27-1.fc25.x86_64 libpsl-0.17.0-1.fc25.x86_64 
libselinux-2.5-13.fc25.x86_64 libssh2-1.8.0-1.fc25.x86_64 
libstdc++-6.3.1-1.fc25.x86_64 libtidy-5.4.0-1.fc25.x86_64 
libtiff-4.0.8-1.fc25.x86_64 libunistring-0.9.4-3.fc24.x86_64 
libwebp-0.5.2-1.fc25.x86_64 libxcb-1.12-1.fc25.x86_64 
libxml2-2.9.4-2.fc25.x86_64 libzip-1.1.3-1.fc25.x86_64 
nspr-4.15.0-1.fc25.x86_64 nss-3.31.0-1.1.fc25.x86_64 
nss-softokn-freebl-3.31.0-1.0.fc25.x86_64 
nss-util-3.31.0-1.0.fc25.x86_64 openldap-2.4.44-11.fc25.x86_64 
openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.41-1.fc25.x86_64 
xz-libs-5.2.2-2.fc24.x86_64

(gdb) bt
#0  0x76d448df in raise () from /lib64/libc.so.6
#1  0x76d464da in abort () from /lib64/libc.so.6
#2  0x76d3cd67 in __assert_fail_base () from /lib64/libc.so.6
#3  0x76d3ce12 in __assert_fail () from /lib64/libc.so.6
#4  0x75fa4fcd in zend_ssa_compute_use_def_chains 
(arena=0x7fffa4a0, op_array=0x7621bcb0, ssa=0x7630c288) at 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090
#5  0x75f9cf9e in zend_dfa_analyze_op_array 
(op_array=0x7621bcb0, ctx=0x7fffa4a0, ssa=0x7630c288, 
flags=0x7630c284)
at 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/dfa_pass.c:102
#6  0x75f82767 in zend_optimize_script (script=0x76284a00, 
optimization_level=2147467263, debug_level=0) at 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_optimizer.c:1268
#7  0x75f6a93b in cache_script_in_shared_memory 
(new_persistent_script=0x76284a00, key=0x76292158 
"/Volumes/dune/www-servers/phpincludes/contentlounge-api/functions.inc.php", 
key_length=73,
from_shared_memory=0x7fffa750) at 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/ZendAccelerator.c:1321
#8  0x75f6beea in persistent_compile_file 
(file_handle=0x7fffa7c0, type=8) at 
/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/ZendAccelerator.c:1

Re: [PHP-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread Nikita Popov 
Can you provide the contents of "/Volumes/dune/www-servers/
phpincludes/contentlounge-api/functions.inc.php"? If this is not publicly
available code, can you send the file to ni...@php.net and dmi...@php.net?
(Or reduce the code -- in this case it should be easy, just delete
functions until it stops happening).

Thanks,
Nikita

PS: bugs.php.net is usually a better venue to report these kinds of issues.

On Fri, Jul 21, 2017 at 12:42 PM, li...@rhsoft.net  wrote:

> /home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090:
> zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0' failed.
>
> below a backtrace of 'opcache' from 7.2.0 beta1, the used 'php.ini' and
> the start of the build-process with configure and compiler params
>
> i used to build HEAD for a long time with my rpm-spec file by just replace
> the tarball, alpha1 did not compile at all, late rbuild was fine as well as
> our cli-cms-testsuite but the intermediate webserver before the second part
> for a PGO-build was broken
>
> currently 'opcache' when "opcache.enable_cli = 1" is enabled crashs very
> early (before any output line of the application)
> _
>
> [builduser@testserver:/rpmbuild/PHP-PGO]$ gdb -ex=r --args
> /home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php -c
> /rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php
> GNU gdb (GDB) Fedora 7.12.1-48.fc25
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  tml>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /home/builduser/rpmbuild/BUILD
> /php-7.2.0/sapi/cli/php...done.
> Starting program: /home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php
> -c /rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Detaching after fork from child process 25798.
> php: 
> /home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090:
> zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0' failed.
>
> Program received signal SIGABRT, Aborted.
> 0x76d448df in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: dnf debuginfo-install
> bzip2-libs-1.0.6-21.fc25.x86_64 cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64
> expat-2.2.1-1.fc25.x86_64 fontconfig-2.12.1-1.fc25.x86_64
> freetype-2.6.5-9.fc25.x86_64 gd-2.2.4-1.fc25.x86_64
> glibc-2.24-9.fc25.x86_64 jbigkit-libs-2.1-5.fc24.x86_64
> keyutils-libs-1.5.9-8.fc24.x86_64 krb5-libs-1.14.4-7.fc25.x86_64
> libX11-1.6.5-1.fc25.x86_64 libXau-1.0.8-6.fc24.x86_64
> libXpm-3.5.12-1.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-9.fc25.x86_64 libcurl-7.51.0-7.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libgomp-6.3.1-1.fc25.x86_64
> libicu-57.1-5.fc25.x86_64 libidn2-2.0.2-1.fc25.x86_64
> libjpeg-turbo-1.5.1-0.fc25.x86_64 libnghttp2-1.13.0-2.fc25.x86_64
> libpng-1.6.27-1.fc25.x86_64 libpsl-0.17.0-1.fc25.x86_64
> libselinux-2.5-13.fc25.x86_64 libssh2-1.8.0-1.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 libtidy-5.4.0-1.fc25.x86_64
> libtiff-4.0.8-1.fc25.x86_64 libunistring-0.9.4-3.fc24.x86_64
> libwebp-0.5.2-1.fc25.x86_64 libxcb-1.12-1.fc25.x86_64
> libxml2-2.9.4-2.fc25.x86_64 libzip-1.1.3-1.fc25.x86_64
> nspr-4.15.0-1.fc25.x86_64 nss-3.31.0-1.1.fc25.x86_64
> nss-softokn-freebl-3.31.0-1.0.fc25.x86_64 nss-util-3.31.0-1.0.fc25.x86_64
> openldap-2.4.44-11.fc25.x86_64 openssl-libs-1.0.2k-1.fc25.x86_64
> pcre-8.41-1.fc25.x86_64 xz-libs-5.2.2-2.fc24.x86_64
> (gdb) bt
> #0  0x76d448df in raise () from /lib64/libc.so.6
> #1  0x76d464da in abort () from /lib64/libc.so.6
> #2  0x76d3cd67 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x76d3ce12 in __assert_fail () from /lib64/libc.so.6
> #4  0x75fa4fcd in zend_ssa_compute_use_def_chains
> (arena=0x7fffa4a0, op_array=0x7621bcb0, ssa=0x7630c288) at
> /home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimiz
> er/zend_ssa.c:1090
> #5  0x75f9cf9e in zend_dfa_analyze_op_array
> (op_array=0x7621bcb0, ctx=0x7fffa4a0, ssa=0x7630c288,
> flags=0x7630c284)
> at /home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimiz
> er/dfa_pass.c:102
> #6  0x75f82767 in zend_optimize_script (script=0x76284a00,
> optimization_level=2147467263, debug_level

Re: [PHP-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread li...@rhsoft.net 

offlist-mail is out

deleting functions until it stops happening is no option in case of a 
global library, the autotest-suite is using them all...


thx for feedback!

Am 21.07.2017 um 13:06 schrieb Nikita Popov:
Can you provide the contents of 
"/Volumes/dune/www-servers/phpincludes/contentlounge-api/functions.inc.php"? 
If this is not publicly available code, can you send the file to 
ni...@php.net  and dmi...@php.net 
? (Or reduce the code -- in this case it should 
be easy, just delete functions until it stops happening).


Thanks,
Nikita

PS: bugs.php.net  is usually a better venue to 
report these kinds of issues.


On Fri, Jul 21, 2017 at 12:42 PM, li...@rhsoft.net 
 mailto:li...@rhsoft.net>> 
wrote:



/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090:
zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0'
failed.

below a backtrace of 'opcache' from 7.2.0 beta1, the used 'php.ini'
and the start of the build-process with configure and compiler params

i used to build HEAD for a long time with my rpm-spec file by just
replace the tarball, alpha1 did not compile at all, late rbuild was
fine as well as our cli-cms-testsuite but the intermediate webserver
before the second part for a PGO-build was broken

currently 'opcache' when "opcache.enable_cli = 1" is enabled crashs
very early (before any output line of the application)
_

[builduser@testserver:/rpmbuild/PHP-PGO]$ gdb -ex=r --args
/home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php -c
/rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php
GNU gdb (GDB) Fedora 7.12.1-48.fc25
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
>.
Find the GDB manual and other documentation resources online at:
>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
/home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php...done.
Starting program:
/home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php -c
/rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 25798.
php:

/home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimizer/zend_ssa.c:1090:
zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0'
failed.

Program received signal SIGABRT, Aborted.
0x76d448df in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
bzip2-libs-1.0.6-21.fc25.x86_64
cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 expat-2.2.1-1.fc25.x86_64
fontconfig-2.12.1-1.fc25.x86_64 freetype-2.6.5-9.fc25.x86_64
gd-2.2.4-1.fc25.x86_64 glibc-2.24-9.fc25.x86_64
jbigkit-libs-2.1-5.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
krb5-libs-1.14.4-7.fc25.x86_64 libX11-1.6.5-1.fc25.x86_64
libXau-1.0.8-6.fc24.x86_64 libXpm-3.5.12-1.fc25.x86_64
libcom_err-1.43.3-1.fc25.x86_64 libcrypt-nss-2.24-9.fc25.x86_64
libcurl-7.51.0-7.fc25.x86_64 libgcc-6.3.1-1.fc25.x86_64
libgomp-6.3.1-1.fc25.x86_64 libicu-57.1-5.fc25.x86_64
libidn2-2.0.2-1.fc25.x86_64 libjpeg-turbo-1.5.1-0.fc25.x86_64
libnghttp2-1.13.0-2.fc25.x86_64 libpng-1.6.27-1.fc25.x86_64
libpsl-0.17.0-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
libssh2-1.8.0-1.fc25.x86_64 libstdc++-6.3.1-1.fc25.x86_64
libtidy-5.4.0-1.fc25.x86_64 libtiff-4.0.8-1.fc25.x86_64
libunistring-0.9.4-3.fc24.x86_64 libwebp-0.5.2-1.fc25.x86_64
libxcb-1.12-1.fc25.x86_64 libxml2-2.9.4-2.fc25.x86_64
libzip-1.1.3-1.fc25.x86_64 nspr-4.15.0-1.fc25.x86_64
nss-3.31.0-1.1.fc25.x86_64 nss-softokn-freebl-3.31.0-1.0.fc25.x86_64
nss-util-3.31.0-1.0.fc25.x86_64 openldap-2.4.44-11.fc25.x86_64
openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.41-1.fc25.x86_64
xz-libs-5.2.2-2.fc24.x86_64
(gdb) bt
#0  0x76d448df in raise () from /lib64/libc.so.6
#1  0x76d464da in abort () from /lib64/libc.so.6
#2  0x76d3cd67 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00

[PHP-DEV] 7.1.8 RC1: compiler warnings

2017-07-21 Thread li...@rhsoft.net 
i don't think it's really helpful opening everytime new bugreports and 
so i changed our build to use "make --quiet" - collected output at the 
bottom and flags/configure at begin to provide some context


they are not at a really high count and probably worse to get silenced
first "prof-gen" and the "prof-use" which enables implicit optimizations 
where i am not sure if it makes a difference

_

+ CXX='gcc -m64 -O3 -mfpmath=sse -mavx -msse2avx -march=sandybridge 
-mtune=sandybridge -D_FORTIFY_SOURCE=2 -fdevirtualize-speculatively 
-fgraphite-identity -fipa-pta -fira-loop-pressure -fivopts -floop-block 
-floop-unroll-and-jam -fmerge-all-constants -fomit-frame-pointer 
-fsemantic-interposition -fstack-protector --param=ssp-buffer-size=8 
-fstrict-aliasing -ftree-loop-distribution -ftree-loop-if-convert 
-ftree-loop-if-convert-stores -ftree-loop-im -ftree-loop-ivcanon 
-fvariable-expansion-in-unroller -fvect-cost-model=unlimited -fwrapv -g0 
-minline-all-stringops -pipe -fno-align-labels -fno-exceptions -fno-gcse 
-fno-math-errno -fuse-ld=gold -fuse-linker-plugin -Wformat 
-Werror=format-security -Wno-stack-protector -Wstrict-aliasing 
-Wa,--noexecstack'


+ SH_LDFLAGS='-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack 
-Wl,-z,nodump -m64 -O3 -mfpmath=sse -mavx -msse2avx -march=sandybridge 
-mtune=sandybridge -D_FORTIFY_SOURCE=2 -fdevirtualize-speculatively 
-fgraphite-identity -fipa-pta -fira-loop-pressure -fivopts -floop-block 
-floop-unroll-and-jam -fmerge-all-constants -fomit-frame-pointer 
-fsemantic-interposition -fstack-protector --param=ssp-buffer-size=8 
-fstrict-aliasing -ftree-loop-distribution -ftree-loop-if-convert 
-ftree-loop-if-convert-stores -ftree-loop-im -ftree-loop-ivcanon 
-fvariable-expansion-in-unroller -fvect-cost-model=unlimited -fwrapv -g0 
-minline-all-stringops -pipe -fno-align-labels -fno-exceptions -fno-gcse 
-fno-math-errno -fuse-ld=gold -fuse-linker-plugin -Wformat 
-Werror=format-security -Wno-stack-protector -Wstrict-aliasing 
-Wa,--noexecstack'


+ LDFLAGS='-Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack 
-Wl,-z,nodump -m64 -O3 -mfpmath=sse -mavx -msse2avx -march=sandybridge 
-mtune=sandybridge -D_FORTIFY_SOURCE=2 -fdevirtualize-speculatively 
-fgraphite-identity -fipa-pta -fira-loop-pressure -fivopts -floop-block 
-floop-unroll-and-jam -fmerge-all-constants -fomit-frame-pointer 
-fsemantic-interposition -fstack-protector --param=ssp-buffer-size=8 
-fstrict-aliasing -ftree-loop-distribution -ftree-loop-if-convert 
-ftree-loop-if-convert-stores -ftree-loop-im -ftree-loop-ivcanon 
-fvariable-expansion-in-unroller -fvect-cost-model=unlimited -fwrapv -g0 
-minline-all-stringops -pipe -fno-align-labels -fno-exceptions -fno-gcse 
-fno-math-errno -fuse-ld=gold -fuse-linker-plugin -Wformat 
-Werror=format-security -Wno-stack-protector -Wstrict-aliasing 
-Wa,--noexecstack -pie -fPIE'

_

+ ./configure --host=x86_64-redhat-linux --build=x86_64-redhat-linux 
--target=x86_64-redhat-linux --prefix=/usr --program-prefix= 
--libdir=/usr/lib64/php --disable-all --disable-dependency-tracking 
--enable-bcmath=shared --enable-calendar=shared --enable-cli 
--enable-ctype=shared --enable-dom=shared --enable-exif=shared 
--enable-fileinfo=shared --enable-filter --enable-hash=shared 
--enable-huge-code-pages --enable-inline-optimization 
--enable-intl=shared --enable-json=shared --enable-libxml 
--enable-mbregex --enable-mbstring=shared --enable-mysqlnd=shared 
--enable-opcache=shared --enable-opcache-jit --enable-pcntl=shared 
--enable-pdo=shared --enable-phar=shared --enable-posix=shared 
--enable-re2c-cgoto --enable-session=shared --enable-shared 
--enable-simplexml=shared --enable-soap=shared --enable-sockets=shared 
--enable-tokenizer=shared --enable-xml=shared --enable-xmlreader=shared 
--enable-xmlwriter=shared --enable-zip=shared --with-apxs2=/usr/bin/apxs 
--with-bz2=shared,/usr --with-config-file-path=/etc 
--with-config-file-scan-dir=/etc/php.lounge.d --with-curl=shared,/usr 
--with-freetype-dir=/usr --with-gd=shared,/usr 
--with-gettext=shared,/usr --with-iconv=shared --with-imap-ssl=/usr 
--with-imap=shared,/usr --with-kerberos=/usr --with-layout=GNU 
--with-libdir=lib64 --with-libedit=shared,/usr --with-libxml-dir=/usr 
--with-libzip=/usr --with-mysql-sock=/var/lib/mysql/mysql.sock 
--with-mysqli=shared,mysqlnd --with-openssl=shared,/usr --with-pcre-jit 
--with-pcre-regex=/usr --with-pdo-mysql=shared,mysqlnd --with-pic 
--with-system-ciphers --with-system-tzdata --with-tidy=shared,/usr 
--with-zlib=shared --with-zlib-dir=/usr --disable-cgi --disable-dmalloc 
--disable-dtrace --disable-gcov --disable-gd-jis-conv --disable-ipv6 
--disable-mysqlnd-compression-support --disable-opcache-file 
--disable-phpdbg --disable-rpath --disable-short-tags --disable-static 
--enable-gcc-global-regs --disable-debug

_

+ make --quiet -j8

Re: [PHP-DEV] bugs.php.net website

2017-07-21 Thread Kalle Sommer Nielsen 
Hi Mathias

2017-07-21 0:39 GMT+02:00 Mathias Grimm :
> Do we have a pre-approved list of libs that we could use?
> For example phpunit. I can't imagine doing it without using that.
> What licenses are approved?
> MIT, BSD?

Most functionality that a bug tracker should do, can and imho should
be implemented in native PHP fairly flawlessly. The only place I can
see that could benefit from a library, if even is github integration,
and even that is done by webhooks which is fairly easy to implement on
its own.

Bugsweb already depend on some PEAR packages, and I for one think
those dependencies should be eliminated, a standard PHP build should
be all thats needed to implement a bug tracker that fit the needs with
that of PHP.

I don't think personally the usage of phpunit is worth it, bugsweb is
so specific to the PHP project, and it should continue to be so and
that is such a minority that would ever run the test suite so the time
spend implementing is better spend in other places, but that is my
personal opinion.

> Regarding the code:
> - Is there any restrictions?
> - Could it be a MVC? What is too complex?

I don't think any of PHP.net's infrastructure should run on an MVC and
we should follow what Rasmus has been advocating at many conferences
over the last years. The front controller is the browser, it does all
the routing we need, instead of adding another layer of complexity
when we already know that we wish to display "bug.php", if we want
some pretty links, then we can simply just put in some RewriteRule[s],
but thats about it.

> I am just trying to understand the mindset a bit as I come from a different
> background and try to come up with something that might be good for
> everybody.

The mindset at php.net, or the PHP project in general is very simple
and basic and it should continue to be so. The language itself is
extremely powerful out of the box as is. Even though the codebase is
from the early PHP4 days, there is nothing wrong with using objects or
anything at all. A class to handle comments would be much more
beneficial as the bug tracker, even more with github integration,
would benefit highly from that as there are many of the same
operations that can be encapsulated in an object vs using procedural
functions.

What should be disencouraged in the current code base is the mess with
global variables and states, which objects to a good extend solves.

> My background is pretty much into object oriented style, SOLID principles
> (to some extend), however, in the end I want to build something stable,
> testable, simple for a child to understand, and, that can be extended and
> last for the long time. Thats what everybody always want :)
>
> I've been thinking about this thing since yesterday (initially was php.net)
> and If I am to approach the bugs.php.net I think I would write an API
> first, leaving the frontend to be done by somebody else as the frontend is
> not what I like to do on my free time.
>
> I am not assuming I would do the whole API alone as other people might be
> interested in joining, although I wouldn't mind doing it by myself, but
> then time is a factor I can't overcome that easy.

I think the bugsweb, if updated, should be a website as it is now,
however it should implement some webhooks to allow integration with
things like git commit hooks that we already have now, people.php.net,
and github. What we need is a website that fits our own needs and
infrastructure, as we are not making a general purpose bug reporting
system. The code is open and freely available and can be adapted to
other projects own needs (like MySQL: http://bugs.mysql.com/ is
running a fork of bugsweb), but that should be about it, extremely
simple and straight forward.

> I would like to come up with a basic MVP that we could iterate until at
> least someone is happy :)
> For the MVP my idea is to keep functionality exactly the same as
> introducing new features will make us not ship it ever.
> First create a rock-solid base and then add features.
>
> So, for that I need to know the hard limits, the DOs and DON'Ts to set some
> boundaries.

As for DON'T's, the main ones would be as I wrote about:
 - No global variables mess, a global variable for database access
shared across procedural functions are perfectly fine tho, and same
for others on a case by case basis
 - No need to implement third party libraries for things essentially
possible in native PHP. We should be neutral, if we use some library,
it can be interpreted as PHP.net favors this or that PHP based project
 - No need to overcomplex code by using practices such as MVCs, we got
the browser as our front controller. We can create abstractions for
commonly used operations, such as comments, bug reports and
authentication objects

Yes I realize that we, the PHP project on many points still can be
considered this odd and special gentlemans club, but most of these
points and procedures has been what we always have done, it is not
that I don't see

Re: [PHP-DEV] php.net website

2017-07-21 Thread Kalle Sommer Nielsen 
Hi Mathias

2017-07-19 19:07 GMT+02:00 Mathias Grimm :
> I was briefly asking Sara about it and as she pointed out it is likely a
> big project but I think we can do something about it.

A side note to all of this, I would personally like to see if parts of
php.net redone, that we can integrate windows.php.net back into the
main website, I was never a big fan of the separation of the two. The
binaries are hosted by Microsoft if I remember correctly and has its
own mirroring system, we could still keep this by just pointing the
downloads to the relevant links to windows.php.net mirroring, as I can
easily agree with the size amount that the Windows binaries do contain
with all these flavors we produce nowadays.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread Nikita Popov 
On Fri, Jul 21, 2017 at 1:14 PM, li...@rhsoft.net  wrote:

> offlist-mail is out
>
> deleting functions until it stops happening is no option in case of a
> global library, the autotest-suite is using them all...
>
> thx for feedback!


Thanks, the issue should be fixed with
https://github.com/php/php-src/commit/69ec51eb0221c76802a5a23e1c86cad1483faed2,
which will also be part of the next 7.2 beta.

Nikita


> Am 21.07.2017 um 13:06 schrieb Nikita Popov:
>
>> Can you provide the contents of "/Volumes/dune/www-servers/php
>> includes/contentlounge-api/functions.inc.php"? If this is not publicly
>> available code, can you send the file to ni...@php.net > ni...@php.net> and dmi...@php.net ? (Or reduce
>> the code -- in this case it should be easy, just delete functions until it
>> stops happening).
>>
>> Thanks,
>> Nikita
>>
>> PS: bugs.php.net  is usually a better venue to
>> report these kinds of issues.
>>
>> On Fri, Jul 21, 2017 at 12:42 PM, li...@rhsoft.net > li...@rhsoft.net> mailto:li...@rhsoft.net>> wrote:
>>
>> /home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimiz
>> er/zend_ssa.c:1090:
>> zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0'
>> failed.
>>
>> below a backtrace of 'opcache' from 7.2.0 beta1, the used 'php.ini'
>> and the start of the build-process with configure and compiler params
>>
>> i used to build HEAD for a long time with my rpm-spec file by just
>> replace the tarball, alpha1 did not compile at all, late rbuild was
>> fine as well as our cli-cms-testsuite but the intermediate webserver
>> before the second part for a PGO-build was broken
>>
>> currently 'opcache' when "opcache.enable_cli = 1" is enabled crashs
>> very early (before any output line of the application)
>> _
>>
>> [builduser@testserver:/rpmbuild/PHP-PGO]$ gdb -ex=r --args
>> /home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php -c
>> /rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php
>> GNU gdb (GDB) Fedora 7.12.1-48.fc25
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> >
>>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> > >.
>> Find the GDB manual and other documentation resources online at:
>> > >.
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from
>> /home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php...done.
>> Starting program:
>> /home/builduser/rpmbuild/BUILD/php-7.2.0/sapi/cli/php -c
>> /rpmbuild/PHP-PGO/php.ini /php-pgo-docroot/cms/autotest.php
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Detaching after fork from child process 25798.
>> php:
>> /home/builduser/rpmbuild/BUILD/php-7.2.0/ext/opcache/Optimiz
>> er/zend_ssa.c:1090:
>> zend_ssa_compute_use_def_chains: Assertion `phi->sources[j] >= 0'
>> failed.
>>
>> Program received signal SIGABRT, Aborted.
>> 0x76d448df in raise () from /lib64/libc.so.6
>> Missing separate debuginfos, use: dnf debuginfo-install
>> bzip2-libs-1.0.6-21.fc25.x86_64
>> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 expat-2.2.1-1.fc25.x86_64
>> fontconfig-2.12.1-1.fc25.x86_64 freetype-2.6.5-9.fc25.x86_64
>> gd-2.2.4-1.fc25.x86_64 glibc-2.24-9.fc25.x86_64
>> jbigkit-libs-2.1-5.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
>> krb5-libs-1.14.4-7.fc25.x86_64 libX11-1.6.5-1.fc25.x86_64
>> libXau-1.0.8-6.fc24.x86_64 libXpm-3.5.12-1.fc25.x86_64
>> libcom_err-1.43.3-1.fc25.x86_64 libcrypt-nss-2.24-9.fc25.x86_64
>> libcurl-7.51.0-7.fc25.x86_64 libgcc-6.3.1-1.fc25.x86_64
>> libgomp-6.3.1-1.fc25.x86_64 libicu-57.1-5.fc25.x86_64
>> libidn2-2.0.2-1.fc25.x86_64 libjpeg-turbo-1.5.1-0.fc25.x86_64
>> libnghttp2-1.13.0-2.fc25.x86_64 libpng-1.6.27-1.fc25.x86_64
>> libpsl-0.17.0-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
>> libssh2-1.8.0-1.fc25.x86_64 libstdc++-6.3.1-1.fc25.x86_64
>> libtidy-5.4.0-1.fc25.x86_64 libtiff-4.0.8-1.fc25.x86_64
>> libunistring-0.9.4-3.fc24.x86_64 libwebp-0.5.2-1.fc25.x86_64
>> libxcb-1.12-1.fc25.x86_64 libxml2-2.9.4-2.fc25.x86_64
>> libzip-1.1.3-1.fc25.x86_64 ns

[PHP-DEV] GOOD Benchmark Results for PHP Master 2017-07-20

2017-07-21 Thread lp_benchmark_robot 
Results for project PHP master, build date 2017-07-20 19:22:06-07:00
commit: a6b529c
previous commit:9c73be8
revision date:  2017-07-20 22:30:58+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.23%  0.10%  3.86%  
  9.37%
:-)   Drupal 7.36 cgi -T1  0.16%  1.84%  3.76%  
  5.75%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13% -0.24%  3.49%  
  4.44%
:-|   bench.php cgi -T100  0.00% -0.03% 45.72%  
  3.33%
:-|  micro_bench.php cgi -T10  0.02%  0.01% 28.59%  
  2.30%
:-|  mandelbrot.php cgi -T100  0.01% -0.05% 42.73%  
  3.43%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2017-07-20/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

[PHP-DEV] Re: PHP 7.2.0 Beta 1 released

2017-07-21 Thread Jan Ehrhardt 
Hi Sara,

Sara Golemon in php.internals (Thu, 20 Jul 2017 08:13:39 -0400):
>The first beta for 7.2.0 was just released and can be downloaded from:
>https://downloads.php.net/~pollita/
[snip]
>Please test it carefully, and report any bugs in the bug system.

I tried running Drupal7 with 7.2.0 Beta 1 and ran into a fatal error,
that does not happen under PHP 7.1.x (Windows, NTS, x64). I do not know
if it is a bug, an omission in UPGRADING or me looking with my nose.
Therefore I did not file a bugreport yet.

The case: class RulesActionContainerUI has a public function form:
> public function form(&$form, &$form_state, $options = array(), $iterator = 
> NULL) {

class RulesRuleUI extends RulesActionContainerUI with a public function
> public function form(&$form, &$form_state, $options = array()) {

Bad programming, but no PHP ever stumbled over it. PHP 7.2.0 Beta 1
issues a fatal error that RulesRuleUI::form must be compatible with
RulesActionContainerUI::form. IMHO a valid remark, but still a BC break.
Is this documented anywhere? Or should the Fatal Error become less
fatal?
-- 
Jan

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

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

2017-07-21 Thread Rasmus Lerdorf 
On Fri, Jul 21, 2017 at 9:50 PM, Jan Ehrhardt  wrote:
>
> I tried running Drupal7 with 7.2.0 Beta 1 and ran into a fatal error,
> that does not happen under PHP 7.1.x (Windows, NTS, x64). I do not know
> if it is a bug, an omission in UPGRADING or me looking with my nose.
> Therefore I did not file a bugreport yet.
>
> The case: class RulesActionContainerUI has a public function form:
> > public function form(&$form, &$form_state, $options = array(), $iterator
> = NULL) {
>
> class RulesRuleUI extends RulesActionContainerUI with a public function
> > public function form(&$form, &$form_state, $options = array()) {
>
> Bad programming, but no PHP ever stumbled over it. PHP 7.2.0 Beta 1
> issues a fatal error that RulesRuleUI::form must be compatible with
> RulesActionContainerUI::form. IMHO a valid remark, but still a BC break.
> Is this documented anywhere? Or should the Fatal Error become less
> fatal?
>

This sounds strange. This hasn't changed in 7.2. It was the same in 7.1 and
7.0. Even in 5.6 and 5.5 it was an E_STRICT. Unless the Windows version has
somehow drifted, but I don't see how that would be possible. Are you sure
it isn't caused by something else?

eg.

 10:10pm thinkpad:~/php-src> cat -n g
 1  php g

Warning: Declaration of C::form(&$form, &$form_state, $options = Array)
should be compatible with P::form(&$form, &$form_state, $options = Array,
$iterator = NULL) in /home/rasmus/php-src/g on line 8
10:10pm thinkpad:~/php-src> php -v
PHP 7.2.0-dev (cli) (built: Jul 21 2017 22:08:10) ( NTS )

10:10pm thinkpad:~/php-src> sudo newphp 71
Activating PHP 7.1.3-dev (cli) (built: Feb 11 2017 09:40:56) ( NTS ) and
restarting php-fpm
10:10pm thinkpad:~/php-src> php g

Warning: Declaration of C::form(&$form, &$form_state, $options = Array)
should be compatible with P::form(&$form, &$form_state, $options = Array,
$iterator = NULL) in /home/rasmus/php-src/g on line 8

10:10pm thinkpad:~/php-src> php -v
PHP 7.1.3-dev (cli) (built: Feb 11 2017 09:40:56) ( NTS )

-Rasmus

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

2017-07-21 Thread Jan Ehrhardt 
Rasmus Lerdorf in php.internals (Fri, 21 Jul 2017 22:15:13 -0400):
>On Fri, Jul 21, 2017 at 9:50 PM, Jan Ehrhardt  wrote:
>
>> The case: class RulesActionContainerUI has a public function form:
>> > public function form(&$form, &$form_state, $options = array(), $iterator
>> = NULL) {
>>
>> class RulesRuleUI extends RulesActionContainerUI with a public function
>> > public function form(&$form, &$form_state, $options = array()) {
>>
>> Bad programming, but no PHP ever stumbled over it. PHP 7.2.0 Beta 1
>> issues a fatal error that RulesRuleUI::form must be compatible with
>> RulesActionContainerUI::form. IMHO a valid remark, but still a BC break.
>> Is this documented anywhere? Or should the Fatal Error become less
>> fatal?
>
>This sounds strange. This hasn't changed in 7.2. It was the same in 7.1 and
>7.0. Even in 5.6 and 5.5 it was an E_STRICT. Unless the Windows version has
>somehow drifted, but I don't see how that would be possible. Are you sure
>it isn't caused by something else?

Your example issues an E_STRICT warning, in both PHP 7.2 nts x64 and PHP
7.1 nts x64, so it must be caused by something else.

I have no faint idea (yet) what causes it. I am doing exactly the same:
switch the config from PHP 7.1 as mod_fcgid to PHP 7.2 as mod_fcgid (or
vice versa), restart Apache (2.4.27) and run 'Flush all caches'. Under
PHP 7.2 I get a fatal error and under PHP 7.1 I do not even get a
warning.

The php.ini's are exactly the same, except for the location of the
error_log. Under PHP 7.2, I am also getting a lot of warnings for
deprecated things:
- create_function()
- each()
- count() on a non-Countable variable
Those were expected. But why Drupal7 transforms one warning into a fatal
error beats me.

Talking about bad programming, this was the weirdest each(), found in
menu.inc:
> list($function, $args) = each($function);
each() is supposed to advance the array pointer, but for which
$function? The first or the last in the statement?
-- 
Jan

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

Re: [PHP-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread li...@rhsoft.net 
thanks - the crash is gone with 
https://git.php.net/?p=php-src.git;a=snapshot;h=3fa76ac54f082d59f3f75a4e166fbc8b3ea8f28b;sf=tgz 
but my pgo-profiling stuff still don't work


since with "/usr/sbin/httpd -X -f /rpmbuild/PHP-PGO/httpd.conf" there is 
only one httpd process the hang looks like a not working 
session_write_close() or otherwise locked and all the (301) responses 
which is currently not clear - the document root itself is placed in a 
symlink


below also a manual run with the existing 7.1.8RC1 working as expected

looks like i need to build one time without profiling and install the 
reulting binaries to debug what is going on here - that all used to work 
with HEAD until 7.2.0 alpha1 around with 7.0/7.1/7.2 and even 
https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit 
unchanged - so the now solved crash came later, i saw that hanging and 
301 behavior for the crash-commit already

__

CONTENTLOUNGE BACKEND-COVERAGE STARTET
 * OK: 
http://localhost:9001/cms/autotests/custom/fileinfo_samples/sample.php (200)

 * OK: http://localhost:9001/cms/autotests/custom/json.php (403)
 * OK: http://localhost:9001/cms/autotests/custom/utf8.php (403)
 * OK: http://localhost:9001/cms/blank.php (301)
 * OK: http://localhost:9001/cms/bottom.php (301)
 * OK: http://localhost:9001/cms/captcha.php (200)
 * OK: http://localhost:9001/cms/cms.php (301)
 * OK: http://localhost:9001/cms/content_haupt.php (301)
 * OK: http://localhost:9001/cms/content_imgmeta2.php (301)
 * OK: http://localhost:9001/cms/content_sub_add.php (301)
 * OK: http://localhost:9001/cms/content_sub_add2.php (301)
 * OK: http://localhost:9001/cms/content_sub_list.php (301)
 * OK: http://localhost:9001/cms/content_sub_list2.php (301)
 * OK: http://localhost:9001/cms/content_sub_move.php (301)
 * OK: http://localhost:9001/cms/content_topframe.php (301)
 * OK: http://localhost:9001/cms/imagegroups.php (301)
 * OK: http://localhost:9001/cms/kalender.php (301)
 * OK: http://localhost:9001/cms/keep_session.php (200)
 * OK: http://localhost:9001/cms/lang_data.php (200)
 * OK: http://localhost:9001/cms/lock.php (301)
 * OK: http://localhost:9001/cms/meta_liste.php (301)
 * OK: http://localhost:9001/cms/modules/admin_css.php (301)
 * OK: http://localhost:9001/cms/modules/admin_ext_content.php (301)
 * OK: http://localhost:9001/cms/modules/admin_glossar.php (301)
 * OK: http://localhost:9001/cms/modules/admin_newsticker.php (301)
 * OK: http://localhost:9001/cms/modules/admin_pressespiegel.php (301)
 * OK: http://localhost:9001/cms/modules/admin_vpages.php (301)
 * OK: http://localhost:9001/cms/modules/bildgalerie/admin/gui_init.php 
(403)
 * OK: 
http://localhost:9001/cms/modules/bildgalerie/admin/image_list.php (301)
 * OK: 
http://localhost:9001/cms/modules/bildgalerie/admin/image_move.php (301)
 * OK: http://localhost:9001/cms/modules/bildgalerie/admin/main_add.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/bildgalerie/admin/main_list.php (301)
 * OK: http://localhost:9001/cms/modules/bildgalerie/admin/sub_add.php 
(301)
 * OK: http://localhost:9001/cms/modules/bildgalerie/admin/sub_list.php 
(301)
 * OK: http://localhost:9001/cms/modules/bildgalerie/admin/sub_move.php 
(301)

 * OK: http://localhost:9001/cms/modules/bildgalerie/verify.php (301)
 * OK: 
http://localhost:9001/cms/modules/block_pages/interface_entrys_liste.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/block_pages/interface_entrys_new.php (301)
 * OK: 
http://localhost:9001/cms/modules/block_pages/interface_groups_liste.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/block_pages/interface_groups_new.php (301)

 * OK: http://localhost:9001/cms/modules/blog/blog_add.php (301)
 * OK: 
http://localhost:9001/cms/modules/contentform/interface_items_form.php (301)
 * OK: 
http://localhost:9001/cms/modules/contentform/interface_items_liste.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/contentform/interface_topics_liste.php 
(301)

 * OK: http://localhost:9001/cms/modules/doc-managment/admin.php (301)
 * OK: 
http://localhost:9001/cms/modules/doc-managment/admin_add_document.php (301)
 * OK: 
http://localhost:9001/cms/modules/doc-managment/admin_add_group.php (301)
 * OK: 
http://localhost:9001/cms/modules/doc-managment/admin_recent_changes.php 
(301)

 * OK: http://localhost:9001/cms/modules/doc-managment/download.php (301)
 * OK: http://localhost:9001/cms/modules/doc-managment/stat.php (301)
 * OK: http://localhost:9001/cms/modules/events_liste.php (301)
 * OK: 
http://localhost:9001/cms/modules/formmailer_generic/interface_container_form.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/formmailer_generic/interface_container_liste.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/formmailer_generic/interface_items_form.php 
(301)
 * OK: 
http://localhost:9001/cms/modules/formmailer_generic/interface_items_liste.php 
(301)

 * OK: http://localhost:9001/cms/modules/formmailer_generic/stat.php (301)

Re: [PHP-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread li...@rhsoft.net 
sadly this is still opcache - when i disable the extension all 301 
becomes 200 responses and the whole suite runs as expected


i can also see the 301 response in the apache log (the "File does not 
exist" before is there because there is a 404-page pointing to a PHP 
script which starts the cms and is supposed to generate the sitemap to 
get the url list


also when i try to access any page on the real webserver in the VM 
firefox stops and says too many redirections


what in the world can result in opcache part of the game every request 
get a 301 response and how do i best debug this to help you fix the 
issue - something currently don't love my codebase


[Sat Jul 22 07:16:49.307064 2017] [core:info] [pid 17241] [client 
127.0.0.1:21520] AH00128: File does not exist: 
/php-pgo-docroot/cms/sitemap.txt

07:16:49 301 GET /cms/sitemap.txt HTTP/1.1 - 1 ms

Am 22.07.2017 um 07:09 schrieb li...@rhsoft.net:
thanks - the crash is gone with 
https://git.php.net/?p=php-src.git;a=snapshot;h=3fa76ac54f082d59f3f75a4e166fbc8b3ea8f28b;sf=tgz 
but my pgo-profiling stuff still don't work


since with "/usr/sbin/httpd -X -f /rpmbuild/PHP-PGO/httpd.conf" there is 
only one httpd process the hang looks like a not working 
session_write_close() or otherwise locked and all the (301) responses 
which is currently not clear - the document root itself is placed in a 
symlink


below also a manual run with the existing 7.1.8RC1 working as expected

looks like i need to build one time without profiling and install the 
reulting binaries to debug what is going on here - that all used to work 
with HEAD until 7.2.0 alpha1 around with 7.0/7.1/7.2 and even 
https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit 
unchanged - so the now solved crash came later, i saw that hanging and 
301 behavior for the crash-commit already

__

CONTENTLOUNGE BACKEND-COVERAGE STARTET
  * OK: 
http://localhost:9001/cms/autotests/custom/fileinfo_samples/sample.php 
(200)

  * OK: http://localhost:9001/cms/autotests/custom/json.php (403)
  * OK: http://localhost:9001/cms/autotests/custom/utf8.php (403)
  * OK: http://localhost:9001/cms/blank.php (301)
  * OK: http://localhost:9001/cms/bottom.php (301)
  * OK: http://localhost:9001/cms/captcha.php (200)
  * OK: http://localhost:9001/cms/cms.php (301)
  * OK: http://localhost:9001/cms/content_haupt.php (301)
  * OK: http://localhost:9001/cms/content_imgmeta2.php (301)
  * OK: http://localhost:9001/cms/content_sub_add.php (301)
  * OK: http://localhost:9001/cms/content_sub_add2.php (301)
  * OK: http://localhost:9001/cms/content_sub_list.php (301)
  * OK: http://localhost:9001/cms/content_sub_list2.php (301)
  * OK: http://localhost:9001/cms/content_sub_move.php (301)
  * OK: http://localhost:9001/cms/content_topframe.php (301)
  * OK: http://localhost:9001/cms/imagegroups.php (301)
  * OK: http://localhost:9001/cms/kalender.php (301)
  * OK: http://localhost:9001/cms/keep_session.php (200)
  * OK: http://localhost:9001/cms/lang_data.php (200)
  * OK: http://localhost:9001/cms/lock.php (301)
  * OK: http://localhost:9001/cms/meta_liste.php (301)
  * OK: http://localhost:9001/cms/modules/admin_css.php (301)
  * OK: http://localhost:9001/cms/modules/admin_ext_content.php (301)
  * OK: http://localhost:9001/cms/modules/admin_glossar.php (301)
  * OK: http://localhost:9001/cms/modules/admin_newsticker.php (301)
  * OK: http://localhost:9001/cms/modules/admin_pressespiegel.php (301)
  * OK: http://localhost:9001/cms/modules/admin_vpages.php (301)
  * OK: http://localhost:9001/cms/modules/bildgalerie/admin/gui_init.php 
(403)
  * OK: 
http://localhost:9001/cms/modules/bildgalerie/admin/image_list.php (301)
  * OK: 
http://localhost:9001/cms/modules/bildgalerie/admin/image_move.php (301)
  * OK: http://localhost:9001/cms/modules/bildgalerie/admin/main_add.php 
(301)
  * OK: 
http://localhost:9001/cms/modules/bildgalerie/admin/main_list.php (301)
  * OK: http://localhost:9001/cms/modules/bildgalerie/admin/sub_add.php 
(301)
  * OK: http://localhost:9001/cms/modules/bildgalerie/admin/sub_list.php 
(301)
  * OK: http://localhost:9001/cms/modules/bildgalerie/admin/sub_move.php 
(301)

  * OK: http://localhost:9001/cms/modules/bildgalerie/verify.php (301)
  * OK: 
http://localhost:9001/cms/modules/block_pages/interface_entrys_liste.php 
(301)
  * OK: 
http://localhost:9001/cms/modules/block_pages/interface_entrys_new.php 
(301)
  * OK: 
http://localhost:9001/cms/modules/block_pages/interface_groups_liste.php 
(301)
  * OK: 
http://localhost:9001/cms/modules/block_pages/interface_groups_new.php 
(301)

  * OK: http://localhost:9001/cms/modules/blog/blog_add.php (301)
  * OK: 
http://localhost:9001/cms/modules/contentform/interface_items_form.php 
(301)
  * OK: 
http://localhost:9001/cms/modules/contentform/interface_items_liste.php 
(301)
  * OK: 
http://localhost:9001/cms/modules/contentform/interface_topics_liste.php 
(301)

  * OK: http://localhost:9

[PHP-DEV] oh my god -> Re: [PHP-DEV] PHP 7.2.0 is broken since the first alpha -> opcache backtrace

2017-07-21 Thread li...@rhsoft.net 
i would say that is pretty one of the biggest major bugs i have ever 
seen because as you can see here even that single code snippet alone is 
enough and the variable $cms_https_only is explicitly set to 0 the line 
before


even if you change it to if($cms_https_only === 1 && 
empty($_SERVER['HTTPS']) && !empty($_SERVER['REQUEST_URI']) && PHP_SAPI 
!== 'cli') the if-condition is executed


well, that explains the endless 301 perfectly.
_

[harry@srv-rhsoft:~]$ curl http://corecms.testserver.rhsoft.net/opcache.php
style='background-color:yellow;color:red;padding:3px;font-family:verdana;font-size:10px;'>/>
Notice:  Undefined variable: cl_api in 
/Volumes/dune/www-servers/corecms/opcache.php on line 6
style='background-color:yellow;color:red;padding:3px;font-family:verdana;font-size:10px;'>/>
Fatal error:  Uncaught Error: Call to a member function 
location() on null in /Volumes/dune/www-servers/corecms/opcache.php:6

Stack trace:
#0 {main}
  thrown in /Volumes/dune/www-servers/corecms/opcache.php on 
line 6


_

[root@testserver:~]$ cat /www/corecms/opcache.php
if($cms_https_only === 1 && empty($_SERVER['HTTPS']) && 
!empty($_SERVER['REQUEST_URI']) && PHP_SAPI !== 'cli')

{
 $cl_api->location(str_replace(PROTOCOL_PREFIX , 'https://', 
rh_serverurl) . $_SERVER['REQUEST_URI'], /**$permanent*/1);

}
_

[harry@srv-rhsoft:/mnt/data/downloads]$ curl 
http://corecms.testserver.rhsoft.net/

HTTPS-ONLY: 0
_

/** https-Redirect verarbeiten */
//exit("HTTPS-ONLY: $cms_https_only");
if($cms_https_only && empty($_SERVER['HTTPS']) && 
!empty($_SERVER['REQUEST_URI']) && PHP_SAPI !== 'cli')

{
 $cl_api->location(str_replace(PROTOCOL_PREFIX , 'https://', 
rh_serverurl) . $_SERVER['REQUEST_URI'], /**$permanent*/1);

}

Am 22.07.2017 um 07:30 schrieb li...@rhsoft.net:
sadly this is still opcache - when i disable the extension all 301 
becomes 200 responses and the whole suite runs as expected


i can also see the 301 response in the apache log (the "File does not 
exist" before is there because there is a 404-page pointing to a PHP 
script which starts the cms and is supposed to generate the sitemap to 
get the url list


also when i try to access any page on the real webserver in the VM 
firefox stops and says too many redirections


what in the world can result in opcache part of the game every request 
get a 301 response and how do i best debug this to help you fix the 
issue - something currently don't love my codebase


[Sat Jul 22 07:16:49.307064 2017] [core:info] [pid 17241] [client 
127.0.0.1:21520] AH00128: File does not exist: 
/php-pgo-docroot/cms/sitemap.txt

07:16:49 301 GET /cms/sitemap.txt HTTP/1.1 - 1 ms

Am 22.07.2017 um 07:09 schrieb li...@rhsoft.net:
thanks - the crash is gone with 
https://git.php.net/?p=php-src.git;a=snapshot;h=3fa76ac54f082d59f3f75a4e166fbc8b3ea8f28b;sf=tgz 
but my pgo-profiling stuff still don't work


since with "/usr/sbin/httpd -X -f /rpmbuild/PHP-PGO/httpd.conf" there 
is only one httpd process the hang looks like a not working 
session_write_close() or otherwise locked and all the (301) responses 
which is currently not clear - the document root itself is placed in a 
symlink


below also a manual run with the existing 7.1.8RC1 working as expected

looks like i need to build one time without profiling and install the 
reulting binaries to debug what is going on here - that all used to 
work with HEAD until 7.2.0 alpha1 around with 7.0/7.1/7.2 and even 
https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit 
unchanged - so the now solved crash came later, i saw that hanging and 
301 behavior for the crash-commit already

__

CONTENTLOUNGE BACKEND-COVERAGE STARTET
  * OK: 
http://localhost:9001/cms/autotests/custom/fileinfo_samples/sample.php 
(200)

  * OK: http://localhost:9001/cms/autotests/custom/json.php (403)
  * OK: http://localhost:9001/cms/autotests/custom/utf8.php (403)
  * OK: http://localhost:9001/cms/blank.php (301)
  * OK: http://localhost:9001/cms/bottom.php (301)
  * OK: http://localhost:9001/cms/captcha.php (200)
  * OK: http://localhost:9001/cms/cms.php (301)
  * OK: http://localhost:9001/cms/content_haupt.php (301)
  * OK: http://localhost:9001/cms/content_imgmeta2.php (301)
  * OK: http://localhost:9001/cms/content_sub_add.php (301)
  * OK: http://localhost:9001/cms/content_sub_add2.php (301)
  * OK: http://localhost:9001/cms/content_sub_list.php (301)
  * OK: http://localhost:9001/cms/content_sub_list2.php (301)
  * OK: http://localhost:9001/cms/content_sub_move.php (301)
  * OK: http://localhost:9001/cms/content_topframe.php (301)
  * OK: http://localhost:9001/cms/imagegroups.php (301)
  * OK: http://localhost:9001/cms/kalender.php (301)
  * OK: http://localhost:9001/cms/keep_session.php (200)
  * OK: http://localhost:9001/cms/lang_data.php (200)
  * OK: http://localhos