Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[li...@rhsoft.net]

Am 30.04.2017 um 01:26 schrieb Yasuo Ohgaki:

On Sun, Apr 30, 2017 at 8:14 AM, Yasuo Ohgaki  wrote:


I don't need your view of HKDF RFC or usage, but I do need good practical
examples that justify your point of view. Please don't waste of your/my
time,
just give some good examples in next reply. Thanks.



BTW, valid (yet not common/proper) example that I can think of is


. PLEASE STOP riding that dead horse - it's even annoying for users 
following the devel-list how you argue on that opic over months - nonody 
shares your view, that's it - accept it


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

[PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit

that below is a "ab -c 50 -n 10" on a Intel(R) Core(TM) i7-3770 CPU 
@ 3.40GHz on our core cms (pgo-build with heavy compiler optimizations, 
only the source tarball deifferent)


currently our production 2x6 core machine with two Intel(R) Xeon(R) CPU 
E5-2643 v3 @ 3.40GHz and the same setup is around 4000-5000 per second 
which is nearly reached by the 6 years old i7 with the JIT


impressive!

JIT:
Requests per second: 3526.56 [#/sec] (mean)
Time per request: 14.178 [ms] (mean)
Time per request: 0.284 [ms] (mean, across all concurrent requests)

7.1:
Requests per second: 1419.87 [#/sec] (mean)
Time per request: 35.214 [ms] (mean)
Time per request: 0.704 [ms] (mean, across all concurrent requests)

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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

and with a demo-page containing all sort of modules and bloat the 
difference is even greater - can't wait to see that in production


is there anything known when it is expected to arrive in the official 
tree or does Zend even hold it back until the point when they can 
suprise with a "we are done, all tests are fine and we can merge it" 
announce?


PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

Am 02.05.2017 um 18:00 schrieb li...@rhsoft.net:

https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit

that below is a "ab -c 50 -n 10" on a Intel(R) Core(TM) i7-3770 CPU 
@ 3.40GHz on our core cms (pgo-build with heavy compiler optimizations, 
only the source tarball deifferent)


currently our production 2x6 core machine with two Intel(R) Xeon(R) CPU 
E5-2643 v3 @ 3.40GHz and the same setup is around 4000-5000 per second 
which is nearly reached by the 6 years old i7 with the JIT


impressive!

JIT:
Requests per second: 3526.56 [#/sec] (mean)
Time per request: 14.178 [ms] (mean)
Time per request: 0.284 [ms] (mean, across all concurrent requests)

7.1:
Requests per second: 1419.87 [#/sec] (mean)
Time per request: 35.214 [ms] (mean)
Time per request: 0.704 [ms] (mean, across all concurrent requests)


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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 02.05.2017 um 20:02 schrieb Nikita Popov:
On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:


and with a demo-page containing all sort of modules and bloat the
difference is even greater - can't wait to see that in production

is there anything known when it is expected to arrive in the
official tree or does Zend even hold it back until the point when
they can suprise with a "we are done, all tests are fine and we can
merge it" announce?

PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

These results are very unlikely. I'm 95% sure your benchmark is broken. 
My first guess would be that you're benchmarking PHP + JIT against PHP 
without opcache. Please share the relevant (opcache-related) portion of 
the php.inis you used


no they are not - since i build RPM packages and even the whole 
spec-file is unchanged, only the tarball changed and the build is highly 
optimized i can assure you for 100% that i compare PHP 7.1.5RC1 with 
https://github.com/zendtech/php-src downloaded today


maybe the PGO-profiling running autotests and fuzzy-calls on the whole 
application as well as 2000 cms-requests combined with the compiler 
flags improves the JIT itself


without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab" multiple 
times on that machine - attached the "php.spec" which is used for the build


in just downloaded the zip from https://github.com/zendtech/php-src, 
renamed it to "php-7.2.0", made a tar.xz archive, changed the version on 
teh frist line in the spec file and fired the build/profiling - nothing 
else changed

___

phpinfo() of the test machine

PHP Version 7.1.5RC1
Build Date May 2 2017 12:19:59

This program makes use of the Zend Scripting Language Engine: Zend 
Engine  v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  Zend 
 OPcache  v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  Technologies 
with  Xdebug  v2.5.3, Copyright  (c)  2002-2017, by  Derick  Rethans


Directive   Local Value Master Value
opcache.blacklist_filename  no valueno value
opcache.consistency_checks  0   0
opcache.dups_fixOff Off
opcache.enable  On  On
opcache.enable_cli  Off Off
opcache.enable_file_overrideOn  On
opcache.error_log   /var/log/php_error.log  /var/log/php_error.log
opcache.fast_shutdown   1   1
opcache.file_update_protection  2   2
opcache.force_restart_timeout   180 180
opcache.huge_code_pages On  On
opcache.inherited_hack  On  On
opcache.interned_strings_buffer 8   8
opcache.lockfile_path   /tmp/tmp
opcache.log_verbosity_level 1   1
opcache.max_accelerated_files   10001000
opcache.max_file_size   327680  327680
opcache.max_wasted_percentage   5   5
opcache.memory_consumption  128 128
opcache.opt_debug_level 0   0
opcache.optimization_level  0x7FFFBFFF  0x7FFFBFFF
opcache.preferred_memory_model  no valueno value
opcache.protect_memory  0   0
opcache.restrict_api	/usr/share/php/zendoptimizer.php 
/usr/share/php/zendoptimizer.php

opcache.revalidate_freq 5   5
opcache.revalidate_path Off Off
opcache.save_comments   0   0
opcache.use_cwd On  On
opcache.validate_permission Off Off
opcache.validate_root   Off Off
opcache.validate_timestamps On
___
Version: 7.1.5

# command 'rpmbuild -bb php.spec --with production' will tune for current hardware while default stays 'sandybridge'
# macro 'php_debug_build' is global (/home/builduser/.rpmmacros) and re-used for pecl-builds while 'debug_build' is local

%global dist  fc%fedora.%(echo $(/usr/bin/date +%Y%m%d.%H%M)).rh
%global phpver7
%global runselftest   0
%global pgo_build 1
%global lto_build 0
%global break_build   0
%global debug_build   0
%global extension_dir %{_libdir}/%{name}/modules

%if %{?_with_production:1}%{!?_with_production:0}
 %global mtune native
 %global rpmsuffix native
 %global php_native_release 1
%else
 %global mtune sandybridge
 %global rpmsuffix sandybridge
 %global php_native_release 0
%endif

%if %php_debug_build
 %global _include_minidebuginfo 1
 %global RH_GCC_DEBUG_OPTION -g3
 %global RH_CONFIGURE_DEBUG_OPTION enable-debug
 %global RH_STRIP_BINARY 0
 %global pgo_build 0
 %global lto_bui

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

that would be the numbers of 7.1.5RC1 *without* opcache

Requests per second:136.46 [#/sec] (mean)
Time per request:   366.405 [ms] (mean)
Time per request:   7.328 [ms] (mean, across all concurrent requests)
Transfer rate:  5429.78 [Kbytes/sec] received

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT: Requests per second: 925.96

same hardware, same scripts, httpd hard restarted
ab -c 50 -n 2

believe it or not - i know my php environemt and what i benchmark :-)

Am 02.05.2017 um 20:12 schrieb li...@rhsoft.net:

Am 02.05.2017 um 20:02 schrieb Nikita Popov:
On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:


and with a demo-page containing all sort of modules and bloat the
difference is even greater - can't wait to see that in production

is there anything known when it is expected to arrive in the
official tree or does Zend even hold it back until the point when
they can suprise with a "we are done, all tests are fine and we can
merge it" announce?

PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

These results are very unlikely. I'm 95% sure your benchmark is 
broken. My first guess would be that you're benchmarking PHP + JIT 
against PHP without opcache. Please share the relevant 
(opcache-related) portion of the php.inis you used


no they are not - since i build RPM packages and even the whole 
spec-file is unchanged, only the tarball changed and the build is highly 
optimized i can assure you for 100% that i compare PHP 7.1.5RC1 with 
https://github.com/zendtech/php-src downloaded today


maybe the PGO-profiling running autotests and fuzzy-calls on the whole 
application as well as 2000 cms-requests combined with the compiler 
flags improves the JIT itself


without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab" multiple 
times on that machine - attached the "php.spec" which is used for the build


in just downloaded the zip from https://github.com/zendtech/php-src, 
renamed it to "php-7.2.0", made a tar.xz archive, changed the version on 
teh frist line in the spec file and fired the build/profiling - nothing 
else changed

___

phpinfo() of the test machine

PHP Version 7.1.5RC1
Build Date May 2 2017 12:19:59

This program makes use of the Zend Scripting Language Engine: Zend 
Engine  v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  Zend 
  OPcache  v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  Technologies 
with  Xdebug  v2.5.3, Copyright  (c)  2002-2017, by  Derick  Rethans


DirectiveLocal ValueMaster Value
opcache.blacklist_filenameno valueno value
opcache.consistency_checks00
opcache.dups_fixOffOff
opcache.enableOnOn
opcache.enable_cliOffOff
opcache.enable_file_overrideOnOn
opcache.error_log/var/log/php_error.log/var/log/php_error.log
opcache.fast_shutdown11
opcache.file_update_protection22
opcache.force_restart_timeout180180
opcache.huge_code_pagesOnOn
opcache.inherited_hackOnOn
opcache.interned_strings_buffer88
opcache.lockfile_path/tmp/tmp
opcache.log_verbosity_level11
opcache.max_accelerated_files10001000
opcache.max_file_size327680327680
opcache.max_wasted_percentage55
opcache.memory_consumption128128
opcache.opt_debug_level00
opcache.optimization_level0x7FFFBFFF0x7FFFBFFF
opcache.preferred_memory_modelno valueno value
opcache.protect_memory00
opcache.restrict_api/usr/share/php/zendoptimizer.php 
/usr/share/php/zendoptimizer.php

opcache.revalidate_freq55
opcache.revalidate_pathOffOff
opcache.save_comments00
opcache.use_cwdOnOn
opcache.validate_permissionOffOff
opcache.validate_rootOffOff
opcache.validate_timestampsOn



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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

and BTW: for the 7.2.0 build i have not built pecl-extensions so the 
application is runnign witout APCu which means loading a single template 
in a core-cms-setup takes 1.6% versus 0.06% of the whole page


maybe one missing relevant information:

* no 3rd party code and micro-optimized to death over months
* 100% declare(strict_types=1); after some months of works
* 99.9% of all functions are using type-hints for all params

could be that the JIT has some benefit from that combined with the 
PGP-profiling and heavily CPU optimizations - i will give it a try and 
leave out the PGO-profiling and compare if the gain stays similar


Am 02.05.2017 um 20:21 schrieb li...@rhsoft.net:

that would be the numbers of 7.1.5RC1 *without* opcache

Requests per second:136.46 [#/sec] (mean)
Time per request:   366.405 [ms] (mean)
Time per request:   7.328 [ms] (mean, across all concurrent requests)
Transfer rate:  5429.78 [Kbytes/sec] received

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT: Requests per second: 925.96

same hardware, same scripts, httpd hard restarted
ab -c 50 -n 2

believe it or not - i know my php environemt and what i benchmark :-)

Am 02.05.2017 um 20:12 schrieb li...@rhsoft.net:

Am 02.05.2017 um 20:02 schrieb Nikita Popov:
On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> <mailto:li...@rhsoft.net>> wrote:


and with a demo-page containing all sort of modules and bloat the
difference is even greater - can't wait to see that in production

is there anything known when it is expected to arrive in the
official tree or does Zend even hold it back until the point when
they can suprise with a "we are done, all tests are fine and we can
merge it" announce?

PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

These results are very unlikely. I'm 95% sure your benchmark is 
broken. My first guess would be that you're benchmarking PHP + JIT 
against PHP without opcache. Please share the relevant 
(opcache-related) portion of the php.inis you used


no they are not - since i build RPM packages and even the whole 
spec-file is unchanged, only the tarball changed and the build is 
highly optimized i can assure you for 100% that i compare PHP 7.1.5RC1 
with https://github.com/zendtech/php-src downloaded today


maybe the PGO-profiling running autotests and fuzzy-calls on the whole 
application as well as 2000 cms-requests combined with the compiler 
flags improves the JIT itself


without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab" 
multiple times on that machine - attached the "php.spec" which is used 
for the build


in just downloaded the zip from https://github.com/zendtech/php-src, 
renamed it to "php-7.2.0", made a tar.xz archive, changed the version 
on teh frist line in the spec file and fired the build/profiling - 
nothing else changed

___

phpinfo() of the test machine

PHP Version 7.1.5RC1
Build Date May 2 2017 12:19:59

This program makes use of the Zend Scripting Language Engine: Zend 
Engine  v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  
Zend   OPcache  v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  
Technologies with  Xdebug  v2.5.3, Copyright  (c)  2002-2017, by  
Derick  Rethans


DirectiveLocal ValueMaster Value
opcache.blacklist_filenameno valueno value
opcache.consistency_checks00
opcache.dups_fixOffOff
opcache.enableOnOn
opcache.enable_cliOffOff
opcache.enable_file_overrideOnOn
opcache.error_log/var/log/php_error.log/var/log/php_error.log
opcache.fast_shutdown11
opcache.file_update_protection22
opcache.force_restart_timeout180180
opcache.huge_code_pagesOnOn
opcache.inherited_hackOnOn
opcache.interned_strings_buffer88
opcache.lockfile_path/tmp/tmp
opcache.log_verbosity_level11
opcache.max_accelerated_files10001000
opcache.max_file_size327680327680
opcache.max_wasted_percentage55
opcache.memory_consumption128128
opcache.opt_debug_level00
opcache.optimization_level0x7FFFBFFF0x7FFFBFFF
opcache.preferred_memory_modelno valueno value
opcache.protect_memory00
opcache.restrict_api/usr/share/php/zendoptimizer.php 
/usr/share/php/zendoptimizer.php

opcache.revalidate_freq55

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 02.05.2017 um 20:53 schrieb Nikita Popov:

These results are very unlikely. I'm 95% sure your benchmark is
broken. My first guess would be that you're benchmarking PHP +
JIT against PHP without opcache. Please share the relevant
(opcache-related) portion of the php.inis you used

no they are not - since i build RPM packages and even the whole
spec-file is unchanged, only the tarball changed and the build is
highly optimized i can assure you for 100% that i compare PHP
7.1.5RC1 with https://github.com/zendtech/php-src
 downloaded today

maybe the PGO-profiling running autotests and fuzzy-calls on the
whole application as well as 2000 cms-requests combined with the
compiler flags improves the JIT itself

without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab"
multiple times on that machine - attached the "php.spec" which is
used for the build

in just downloaded the zip from https://github.com/zendtech/php-src
, renamed it to "php-7.2.0",
made a tar.xz archive, changed the version on teh frist line in the
spec file and fired the build/profiling - nothing else changed

>

You have xdebug enabled...


loaded, but not enabled

xdebug.default_enable = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT PGO: Requests per second: 925.96
7.2.0 JIT NON-PGO: Requests per second: 849.99

around 8% are the difference with or without PGO, no idea how much 
strict-types and a 100% typehinted codebase makes a difference to the 
JIT operations




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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 02.05.2017 um 21:12 schrieb Nikita Popov:
On Tue, May 2, 2017 at 9:04 PM, li...@rhsoft.net 


You have xdebug enabled...


loaded, but not enabled

xdebug.default_enable = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT PGO: Requests per second: 925.96
7.2.0 JIT NON-PGO: Requests per second: 849.99

around 8% are the difference with or without PGO, no idea how much
strict-types and a 100% typehinted codebase makes a difference to
the JIT operations

This is a common misconception. If you have loaded xdebug you will incur 
a major performance hit, regardless of ini settings. 
xdebug.default_enable is a badly named option, which controls display of 
stack traces, not whether xdebug is enabled. As far as I know, there is 
no way to disable xdebug once it has been loaded.


Please unload xdebug and try again


argh - when the trigger is set to generate profiling files runtime is 
doubled compared with xdebug just loaded but indeed xdebug has a massive 
impact


7.1.5 PGO: Requests per second: 886.63
7.2.0 JIT PGO: Requests per second: 925.96

OK, than it are "only" 5% on a highly optimized codebase

interesting is the impact of PGO-profiling which has likely a 
code-coverage nearly to 95% and that without xdebug our cms-system seems 
to be that efficient that it nearly runs as fast on a quad-core i7 from 
2011 than on a 12-core Xeon from 2015.


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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 03.05.2017 um 02:37 schrieb Sara Golemon:

On Tue, May 2, 2017 at 2:51 PM, li...@rhsoft.net  wrote:

OK, than it are "only" 5% on a highly optimized codebase


Awww... that makes me kinda sad to hear.  But perhaps with more work
that needle can be moved upwards.

One question which I didn't see answered (in my admittedly quick
scan): What codebase are you testing against?  Wordpress stock
install?


100% internal codebase without 3rd party libraries developed over the 
last 15 years and in the meantime 100% 
strict-types/typehints/return-types only missing some commented 
nullable/void return types because i need to wait with 7.1.x for another 
busy guy with some of his instances :-)


the profiling system is our internal demo-system with every depolyable 
module installed, runs the auto-testsuite inclduing refelection fuzzy-calls


* override config and switch to a clean database
* create 86 tables running the installer
* 60 unit tests (heavy sound on a RAID10 HDD system)
* 1200 reflection-fuzzy calls with random params to methdos
* calling every backend url with a configured admin user
* spider over 1600 frontend urls (curl, dom)
* controlled by a bash/php mix running also the intermediate CLI

that beast is highly optimized and the core-cms with just 4 navigation 
points and some lines of text has 12 function calls above 1% in xdebug :-)


well, the demo-install for profiling has magnitudes more running code

so 5% is not that bad - PHP 5.6 to 7.0 brought only 45% on that codebase 
while in the meantime the performance of the code got doubled at it's 
own (thanks xdebug) - hence someone heard my cry "WTF unbelievebale " 
after the first run not realize that the loaded xdebug without JIT makes 
most of the factor 2.5 difference while my epectation was 5-10% if any 
measureable improvement at all


http://corecms.thelounge.net/show_content.php?sid=2
0.0027 / 0.0013 - cuurently running on 7.0.18

0.0027: Header always set "X-Response-Time""%D us"
0.0013: microtime(true) first line versus microtime(true) final
__

3500 requests/second with 7.2-JIT on a 4-core i7 versus 4500/second with 
7.8.18 on a 12-core Xeon tells me that PHP itself is only some part of 
the runtime of the ab-benchmark given that "ab" on my testmachine eats 
nearly one of the 4 cores at it's own and even under 100% load generate 
times in the browser stays below 0.01 seconds

__

250 sequentiell curl requests parsing the "X-Response-Time" average with 
identical content


DYNAMIC CMS: 2382 us
STATIC HTM:  242 us
STATIC PHP:  288 us

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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 03.05.2017 um 05:37 schrieb Sara Golemon:

On Tue, May 2, 2017 at 10:19 PM, li...@rhsoft.net  wrote:

100% internal codebase without 3rd party libraries developed over the last
15 years and in the meantime 100% strict-types/typehints/return-types only
missing some commented nullable/void return types because i need to wait
with 7.1.x for another busy guy with some of his instances :-)


Would you mind running some numbers against "commodity
apps/frameworks" (e.g. Wordpress, ZendFramework, Laravel, etc...)  I
expect that will be far more telling (in a potentially positive way).
For example, HHVM performs best on "highly optimized code", which is
why it tends to look a bit tepid against PHP 7 when run on "normal"


sorry, all my setups have a lot of stuff in the config to kill stuff 
like wordpress/joomla/typo3 so nobody comes to the idea installing after 
that badly mainatined stuff on my machines (for our own CMS there is a 
deplyoment system maintaining 100, 200 or 1000 instances with s single 
shell command)



codebases (particularly WP, which is in many ways not JIT friendly).
I realize the proof of concept jit branch is probably missing quite a
bit of optimizations compared to where it will land, so it may not
make then same kind of difference, but hey... curiosity killed the
cat.


WP is not friendly to anything :-)

on the other hand i guess that more the code itself is bloatet the 
impact of performance improvements is bigger compared to my code where 
httpd and connection handling takes as long as the application while 20% 
of my runtime costs are database connections and queries which don't get 
faster in any case



the profiling system is our internal demo-system with every depolyable
module installed, runs the auto-testsuite inclduing refelection fuzzy-calls


Sounds very comprehensive and I'm glad you're using such a heavy
benchmarking suite. :D


well, it was more about "how do i feed 
https://software.intel.com/en-us/blogs/2015/10/09/pgo-let-it-go-php with 
as much as possible runtime informations" and later "how do i get that 
beast deployable again after rewrite the whole codebase to native PHP7 
with minimized fallout on type-errors"



so 5% is not that bad


Apologies if I gave the impression that I felt it was "bad".  My
expressed disappointment was only relative to the headline "ZOMGWTFBBQ
100% GAIN" headline (which I think most of us regarded as probably
wrong in some way due to the early-days nature of the jit branch). :)


yeah, i thought i start a party after the first result which maxed out 
at 4200/seconds after a few thousand requests on my workstation looking 
in the direction of the 12-core Xeon "and what will you do with that" :-)


what will be interesting with the JIT is how it benefits from newer CPU 
architectures, currently we optimize for sandybdrige, with next summer 
the cluster nodes will be replaced and the VMware EVC mode raised to 
skylake leading to maintain a different PHP PGP-build with -mtune=native


looking at "Use AVX instructions (if enabled and available)" 
https://github.com/zendtech/php-src/commit/d9474c784041745a455dd5be06b52c0029e40697 
there will be some space of improvement on both sides, the PHP binary 
itself as well as what code the JIT can prodcue at the end (skylake Xeon 
will intoduce AVX512 as example)


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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 03.05.2017 um 13:20 schrieb Eli:

Would you mind running some numbers against "commodity
apps/frameworks" (e.g. Wordpress, ZendFramework, Laravel, etc...)  I
expect that will be far more telling (in a potentially positive way).
For example, HHVM performs best on "highly optimized code", which is
why it tends to look a bit tepid against PHP 7 when run on "normal"


sorry, all my setups have a lot of stuff in the config to kill stuff like 
wordpress/joomla/typo3 so nobody comes to the idea installing after that badly 
mainatined stuff on my machines (for our own CMS there is a deplyoment system 
maintaining 100, 200 or 1000 instances with s single shell command)


However the majority of PHP in the wild is in fact running on these commodity 
frameworks.   Especially Wordpress.

So if your numbers don't show the benefit there. Or even show a decrease.  Then 
it's going to be rough moving forward.


well, i think it's also valueable to know that the JIT don't harm or 
even improve slightly code which is not mainstream and has already a 
small footprint


for wordpress, joomla and other mainstream software people which use it 
in their daily workflow are the better ones for setup demosystems 
compared to when i loveless setup soemthing probably never used that way 
in real life


what i can offer is everytime when the GIT branch get noticeable changes 
to fireup a build and watch how it envolves here in case of performance


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

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[li...@rhsoft.net]

Am 09.05.2017 um 23:36 schrieb Yasuo Ohgaki:

Hi,

On Sun, Apr 30, 2017 at 3:55 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:


. PLEASE STOP riding that dead horse - it's even annoying for
users following the devel-list how you argue on that opic over
months - nonody shares your view, that's it - accept it


Apparently not.
You obviously do not understand what is the issue


i understand the issue - you just don't accept that it was refused - 
period - deal with it


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

Re: [PHP-DEV] HYBRID VM

[li...@rhsoft.net]

Am 10.05.2017 um 08:21 schrieb André Rømcke:

On 5 May 2017, at 22:06, Dmitry Stogov  wrote:

It provides comparabele improvement on smal benchmarks, without degradation on 
real apps.
It can be compiled in reasonale time (GOTO requres significant time anda lot of 
memory).
Finally HYBRID fallbak to CALL if compiler doesn't provide necessary extensions.


While at it how does this compare to jit branch?


obviously it's not "one or the other"

https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit
https://github.com/zendtech/php-src/commit/d570de2cb6a88d9772f510d112a04ce4022110cd

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

Re: [PHP-DEV] TLS v1.2 -only- deployments

[li...@rhsoft.net]

Am 11.05.2017 um 13:08 schrieb Anatol Belski:

-Original Message-
From: Thomas Hruska [mailto:thru...@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development 
Subject: [PHP-DEV] TLS v1.2 -only- deployments

Over the past two weeks, I've observed quite a bit of PHP 7+ userland code
breaking due to remote hosts switching to a TLS 1.2 only policy.
For various specific reasons, I strongly suspect that PCI DSS 3.1 
implementations
or compliance audits against that spec have something to do with the changes
that I'm seeing:

https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls

In just the last two weeks, I've seen completely unrelated servers of various
vendors go offline for an upgrade.  When they come back up a short bit later,
they are suddenly configured for TLS 1.2 only.  Running a Qualys SSL labs test
confirms the changes.  It's a rather specific change to encounter in such a 
short
period of time.

PHP userland code (e.g. stream_socket_client()) is unable to connect to such
hosts via "tls://" host strings.  The string has to be updated to use the 
version-
specific string "tlsv1.2://" before the connecting code starts working again.


I think in any case, especially if apps are branch specific, explicit TSL 1.2 
is probably the best way, like anything explicit in security


yesm boiut what *really* annoys me is that "tls://" don't just default 
to the most secure connection *both* sides support


what do you do in a few years - change again userland php-code to 
"tlsv1.3://" - franly that don't belong in any PHP script at all because 
PHP is nothing else than i client here and a random developer sould not 
need to know ahything about that low level things


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

Re: [PHP-DEV] TLS v1.2 -only- deployments

[li...@rhsoft.net]

Am 11.05.2017 um 14:18 schrieb Anatol Belski:




-Original Message-
From: li...@rhsoft.net [mailto:li...@rhsoft.net]
Sent: Thursday, May 11, 2017 1:25 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments


Am 11.05.2017 um 13:08 schrieb Anatol Belski:

-Original Message-
From: Thomas Hruska [mailto:thru...@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development 
Subject: [PHP-DEV] TLS v1.2 -only- deployments

Over the past two weeks, I've observed quite a bit of PHP 7+ userland
code breaking due to remote hosts switching to a TLS 1.2 only policy.
For various specific reasons, I strongly suspect that PCI DSS 3.1
implementations or compliance audits against that spec have something
to do with the changes that I'm seeing:

https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tl
s

In just the last two weeks, I've seen completely unrelated servers of
various vendors go offline for an upgrade.  When they come back up a
short bit later, they are suddenly configured for TLS 1.2 only.
Running a Qualys SSL labs test confirms the changes.  It's a rather
specific change to encounter in such a short period of time.

PHP userland code (e.g. stream_socket_client()) is unable to connect
to such hosts via "tls://" host strings.  The string has to be
updated to use the version- specific string "tlsv1.2://" before the connecting

code starts working again.



I think in any case, especially if apps are branch specific, explicit
TSL 1.2 is probably the best way, like anything explicit in security


yes but what *really* annoys me is that "tls://" don't just default to the most
secure connection *both* sides support


Yes, that's the current implementation. If there can be a better 
implementation, perhaps it were worth it to pursue.


shouldn't "tls://" just handover the handshake stuff to openssl?


what do you do in a few years - change again userland php-code to "tlsv1.3://" -
franly that don't belong in any PHP script at all because PHP is nothing else 
than i
client here and a random developer sould not need to know ahything about that
low level things


For things like payments - certainly, the explicit highest security goes over 
any automatic negotiation. Standards don't change every day and a maintained 
app should follow the changes in the industry. Fe the particular doc there 
suggest an explicit migration path for the branch specific apps, explicitly 
mentioning to prefer TSL 1.2. On the other hand, for general purposes, one 
would want to keep the supported range as wide as possible


it's fine that you can write "tlsv1.2://", "tlsv1.3://" explicit where 
it makes sense but you should not need to do so and just be able to say 
"tls://" and except that the underlying ssl library does the best 
possible handshake


the current implementation makes "SSLHonorCipherOrder" and 
"SSLCipherSuite" with a ordering to pass ssllabs on the serversie 
pointless when a stupid client just uses TLS1.0


maybe the underlying reason is the same that mysqli for encrypted 
database connections is using "DHE-RSA-AES128-SHA" while /etc/my.cnf on 
the database server has "ssl-cipher = 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:RSA-AES256-SHA"


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

Re: [PHP-DEV] Deprecate INTL_IDNA_VARIANT_2003

[li...@rhsoft.net]

Am 13.05.2017 um 17:30 schrieb Christoph M. Becker:

On 13.05.2017 at 17:14, Niklas Keller wrote:


2016-11-24 19:25 GMT+01:00 Christoph M. Becker :


I've just noticed that ICU has deprecated the IDNA 2003 related
functions as of ICU 55[1].  Therefore I suggest that we deprecate
INTL_IDNA_VARIANT_2003 as of PHP 7.2, make INTL_IDNA_VARIANT_UTS46 the
default as of PHP 8.0(?) (or even remove this parameter?), and remove
INT_IDNA_VARIANT_2003 as of PHP 8.0.  Otherwise we may get into trouble
if ICU removes these functions.

Thoughts?  Does this change require an RFC?


Please update the defaults for e.g.
http://php.net/manual/en/function.idn-to-ascii.php, too. A default call
shouldn't result in a deprecation notice IMO.


Changing the defaults in PHP 7.4 first has been part of the accepted
RFC, see
.


then supress the deprecation warning in case it's the internal default

enforce people changing their PHP code which relies on "well, normally 
the defaults should just work" is doomed - in the next iteration a few 
years later you have to touch it again *because* of that




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

Re: [PHP-DEV] HYBRID VM

[li...@rhsoft.net]

Am 15.05.2017 um 16:43 schrieb Dmitry Stogov:

php zend_vm_gen.php --with-vm-kind=HYBRID

make


shouldn't that be a ./configure option?
calls like "php zend_vm_gen.php" are not self contained in a rpmbuild



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

Re: [PHP-DEV] HYBRID VM

[li...@rhsoft.net]

Am 15.05.2017 um 17:30 schrieb Sara Golemon:

On Mon, May 15, 2017 at 9:51 AM, li...@rhsoft.net  wrote:

Am 15.05.2017 um 16:43 schrieb Dmitry Stogov:


php zend_vm_gen.php --with-vm-kind=HYBRID


shouldn't that be a ./configure option?
calls like "php zend_vm_gen.php" are not self contained in a rpmbuild


atm, no.  The VM gen is (and has been since 5.0) a development time
generator which is checked into GIT (because it requires PHP to be
built to run, and must run before PHP is built).  rpmbuilders
(probably) never need worry about selecting alternate VMs, but if they
do there must be a means to patch codebases before building (distros
do this routinely), hooking into that should be a possibility.


rpmbuilders are not only distributions

people which optimize PHP for their hardware and with PGO profiling 
(like me) and anybody else building from source does himself a favour 
when build packages


i looked at that script and found also ZEND_VM_KIND_GOTO not sure what 
and if that has to to with --enable-re2c-cgoto which is enabled here



That said, the only argument against adding it as a ./configure option
is that it's a bootstrap step (as mentioned above).  I suppose we
could use the checked in version of the VM when the option isn't
specified, and error if one tried to specify the option without having
a PHP version already around.

That's orthogonal to this thread, however.

Dmitry; You've got my thumbs up. No need for an RFC for something
purely internal like this.


ok

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

Re: [PHP-DEV] HYBRID VM

[li...@rhsoft.net]

Am 15.05.2017 um 16:43 schrieb Dmitry Stogov:

Hi,


Recently, I committed HYBRID VM into master, but didn't enable it by default 
yet.

It provides significant performance improvement on small benchmarks (1.5 times 
faster on bench.php) and slight improvement on real-life apps (1-2% on 
wordpress). Currently it improves PHP only on x86, x86_64 and PPC compiled with 
GCC.

Anyone may regenerate and test it.


php zend_vm_gen.php --with-vm-kind=HYBRID

make


benchmarks for our inhouse CMS on my home-machine

* Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
* PGO-Build -mtune=sandybridge

for our application there is real difference, just look at the two 
different runs with the hybrid-vm - which is at least not bad at the end


"corecms" = a completly stripped own instance of our inhouse cms

"contentlounge" = a expensive "generic formmailer" and other modules on 
the page


the machine runs in a room with a high temperature and i faced larger 
differences even with the same build and nothing changed, maybe other 
applications will see more speed improvement, the codebase is highly 
optimized down to OPCODEs looking at xdebug-profiles and probably the 
most tiny codebase depending on the configured modules out there given a 
total LOC around 25 lines in theory (but that includes also admin 
baclaneds for all sort of servers)

___

/usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=CALL

Server Hostname:corecms
Concurrency Level:  50
Time taken for tests:   30.158 seconds
Complete requests:  10
Failed requests:0
Total transferred:  383563326 bytes
HTML transferred:   346464592 bytes
Requests per second:3315.84 [#/sec] (mean)
Time per request:   15.079 [ms] (mean)
Time per request:   0.302 [ms] (mean, across all concurrent requests)
Transfer rate:  12420.25 [Kbytes/sec] received

Server Hostname:contentlounge
Concurrency Level:  50
Time taken for tests:   109.291 seconds
Complete requests:  10
Failed requests:0
Total transferred:  4806868605 bytes
HTML transferred:   4758197006 bytes
Requests per second:914.99 [#/sec] (mean)
Time per request:   54.645 [ms] (mean)
Time per request:   1.093 [ms] (mean, across all concurrent requests)
Transfer rate:  42951.58 [Kbytes/sec] received
___

/usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=HYBRID

Server Hostname:corecms
Concurrency Level:  50
Time taken for tests:   31.528 seconds
Complete requests:  10
Failed requests:0
Total transferred:  383561944 bytes
HTML transferred:   346463930 bytes
Requests per second:3171.77 [#/sec] (mean)
Time per request:   15.764 [ms] (mean)
Time per request:   0.315 [ms] (mean, across all concurrent requests)
Transfer rate:  11880.57 [Kbytes/sec] received

Server Hostname:corecms
Concurrency Level:  50
Time taken for tests:   31.248 seconds
Complete requests:  10
Failed requests:0
Total transferred:  383561400 bytes
HTML transferred:   346462104 bytes
Requests per second:3200.20 [#/sec] (mean)
Time per request:   15.624 [ms] (mean)
Time per request:   0.312 [ms] (mean, across all concurrent requests)
Transfer rate:  11987.03 [Kbytes/sec] received

Server Hostname:contentlounge
Concurrency Level:  50
Time taken for tests:   106.127 seconds
Complete requests:  10
Failed requests:0
Total transferred:  4806870511 bytes
HTML transferred:   4758196867 bytes
Requests per second:942.27 [#/sec] (mean)
Time per request:   53.063 [ms] (mean)
Time per request:   1.061 [ms] (mean, across all concurrent requests)
Transfer rate:  44232.14 [Kbytes/sec] received

Server Hostname:contentlounge
Concurrency Level:  50
Time taken for tests:   107.479 seconds
Complete requests:  10
Failed requests:0
Total transferred:  4806867967 bytes
HTML transferred:   4758194770 bytes
Requests per second:930.41 [#/sec] (mean)
Time per request:   53.739 [ms] (mean)
Time per request:   1.075 [ms] (mean, across all concurrent requests)
Transfer rate:  43675.61 [Kbytes/sec] received
___

for rpmbuilders:

%prep
export LANG=C
%setup -q -n php-%{version}
%patch1 -p1 -b .realpath
%if "%{version}" >= "7.1.0"
%patch3 -p1 -b .systzdata-71
%else
%patch2 -p1 -b .systzdata-70
%endif

# rebuild 'data_file.c' from current system libmagic starting with PHP 
7.2 and when /usr/bin/php is installed

%if "%{version}" >= "7.2.0"
 if [ -f /usr/bin/php ]; then
  /usr/bin/php ext/fileinfo/create_data_file.php 
/usr/share/misc/magic.mgc > ext/fileinfo/data_file.c

 fi
%endif

# generate zend-vm when /usr/bin/php is installed
%if "%{version}" >= "7.2.0"
 if [ -f /usr/bin/php ]; then
  /

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[li...@rhsoft.net]

Am 17.05.2017 um 17:00 schrieb Andreas Heigl:







seriously a signature on top breaks reply and quotes for any sane MUA 
which strips signatures and so quotes only stuff on top of the "-- " 
line


> Just a stupid question for a non-regular: Why not a
> separate repo? In the end run-tests.php is a PHP-application
> and not a C one and with tests and all such things to do
> it might be wasier to develop independent from the PHP-sources.

that's invisible for endusers

> It needs to be available to the PHP-sources in the end, but that 
might > be possible by using git-submodules (or downloading a phar-file?)


a sane RPM build is using "run-tests.php" after compilation abd before 
generate the final packages


* configure
* make prof-gen
* run application code
* make prof-clean
* make prof-use
* run-tests.sh
* build rpm packages


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

Re: [PHP-DEV] messages not delivering?

[li...@rhsoft.net]

Am 18.05.2017 um 10:45 schrieb Andrey Andreev:

http://news.php.net/php.internals/99093
http://news.php.net/php.internals/99094

Again, failing DMARC authentication


which is unavoidable when the list mangles subject with a prefix and 
body with a list footer which breaks DKIM unconditionally


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

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[li...@rhsoft.net]

Am 18.05.2017 um 12:08 schrieb Marco Pivetta:

On Thu, May 18, 2017 at 2:35 AM, Johannes Schlüter 
wrote:


On Mi, 2017-05-17 at 23:30 +0200, Marco Pivetta wrote:

Is Sebastian copied in here? Why can't we just use the super-battle-
tested
PHPUnit? It supports phpt and a ton of plugins, plus everyone uses it
and
is familiar with it.


PHPUnit is huge. run-tests is a small script in a single file which I
can quickly edit. For PHPUnit I have multiple files and need tooling to
phar them up.



You don't need to phar them up - just run a typical composer installation,
like everyone else, and like every PHP package running CI on
travis-ci/circle-ci/continuous-php ever built in the last 5 years.
At this point, composer and phpunit are such big players that breaking them
or breaking PHP makes no difference at all for the user-base


who is the userbase you are talking about?

* no composer here
* no php-unit here

but 25 LOC and own testsuites and own deployment systems written in 
PHP without any third party libraries driving some hundret domains in 
place as well as a rpmbuild running "run-tests.php" as part of the build 
process


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

Re: [PHP-DEV] [RFC] [Discussion] UUID

[li...@rhsoft.net]

Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:

Hey internals!

I haven't written the RFC yet,


Please don't forget to include in the RFC a justification for why this
should be part of PHP core, rather than a library


because as developer in reality you can not use and rely on features 
which needs to install some pecl-library when it is supposed to be used 
on typical hosting packages


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

Re: [PHP-DEV] [RFC] [Discussion] UUID

[li...@rhsoft.net]

Am 24.05.2017 um 17:04 schrieb Larry Garfield:

On 05/24/2017 04:31 AM, li...@rhsoft.net wrote:


Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:

Hey internals!

I haven't written the RFC yet,


Please don't forget to include in the RFC a justification for why this
should be part of PHP core, rather than a library


because as developer in reality you can not use and rely on features 
which needs to install some pecl-library when it is supposed to be 
used on typical hosting packages


It doesn't have to be a PECL library.  I agree that a project requiring 
a PECL library greatly limits its potential reach, but with Composer 
user-space libraries are totally easy to install. There's a nice and 
popular UUID implementation already


frankly get out of my sight with composer

i maintain the whole webstacke for many years at my own (rpm packages) 
and so the Fedora repos have excluded anything relevant to PHP - trying 
to build composer by just download the src.rpm ends in a ton of build 
dependencies, bootsrap stuff because of cyclic dependencies, frameworks 
nobody needs and wants in environments where 3rd party code is 
discouraged because it becomes a problem sooner or later in case of 
upgrades and so composer is just a red flag for me until a PHP build 
spits out a /usr/bin/composer binary which is self contained


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

Re: [PHP-DEV] [RFC] [Discussion] UUID

[li...@rhsoft.net]

Am 24.05.2017 um 17:11 schrieb Levi Morrison:

On Wed, May 24, 2017 at 9:04 AM, Larry Garfield 
wrote:


On 05/24/2017 04:31 AM, li...@rhsoft.net wrote:


Am 24.05.2017 um 11:27 schrieb Dan Ackroyd:


Hey internals!


I haven't written the RFC yet,


Please don't forget to include in the RFC a justification for why this
should be part of PHP core, rather than a library


because as developer in reality you can not use and rely on features
which needs to install some pecl-library when it is supposed to be used on
typical hosting packages


It doesn't have to be a PECL library.  I agree that a project requiring a
PECL library greatly limits its potential reach, but with Composer
user-space libraries are totally easy to install. There's a nice and
popular UUID implementation already:

https://packagist.org/packages/ramsey/uuid

Note: That doesn't mean adding UUID functionality to PHP core/standard lib
is a bad idea; discussing that is fine.  But the "no one will be able to
use it otherwise" argument is substantially less compelling than it was
even 5 years ago.


By the way there already is a PECL package for a UUID library:
https://pecl.php.net/package/uuid. I would like to see compelling reasons
why we shouldn't rally around that package
because when you end in a library/extension for each and every trivial 
function your codebase becomes a mess - why not PECL i have explained 
before the post you quoted and why composer as it is working nwo is a 
no-go in the follow-up response


not that i care much of *that* function but when in the future every 
functionality ends in pecl and/or composer, well, my list what not to 
touch will grow in the same speed


we maintain a large codebase (25 LOC) over 15 years and the only 3rd 
party library is 'phpmailer' and besides php-pecl-apcu and 
php-pecl-imagick on prodcution machines there are no 3rd partly librarie 
and won't be that soon - not interested in the mess 10 years later while 
 currently i can deploy hundrets of instances with a self-contained 
deployment software using the same framework as the application and it's 
modules and build/test a php-build whithn a few minutes be it 7.0.x, 
7.1.x, 7.2.x


with every single external dependency that becomes harder

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

Re: [PHP-DEV] [RFC] [Discussion] UUID

[li...@rhsoft.net]

Am 24.05.2017 um 18:30 schrieb Remi Collet:

Le 24/05/2017 à 17:21, li...@rhsoft.net a écrit :


frankly get out of my sight with composer

i maintain the whole webstacke for many years at my own (rpm packages)
and so the Fedora repos have excluded anything relevant to PHP - trying
to build composer by just download the src.rpm ends in a ton of build
dependencies, bootsrap stuff because of cyclic dependencies, frameworks
nobody needs and wants in environments where 3rd party code is
discouraged because it becomes a problem sooner or later in case of
upgrades and so composer is just a red flag for me until a PHP build
spits out a /usr/bin/composer binary which is self contained



I definitively don't understand your point.


why?


If you want composer, you will ALWAYS need Symfony (and some other
pieces). Composer is symfony app.


and here the problem starts

i DO NOT want Symfony because i don't have a need for any 3rd party 
software just because i don't have "fire and forget" projects - i have 
*one* project for a lifetime which covers all


* frameworks
* abstraction layers
* on top a CMS
* on top of the CMS customer sites
* on top of the CMS admin backaneds for dns/epp/httpd/mail...
* and since the framework as well as the CMS support CLI mode
  a ton of automation for maintain services, cms-tasks, cleanups
  and all needed admin staff for the whole infrastructure

from the moment on a introdcue 3rd party frameworks i am no longer free 
to build PHP as i like it and the version i want


stripped down to a minimum and only enable and compile needed 
extensions, package everything as loadable extensions and manage the 
whole stuff with rpm-meta-packages


the only acceptable things here are PHAR files like phpdoc

[harry@srv-rhsoft:~]$ php -n -m
[PHP Modules]
Core
date
filter
libxml
pcre
Reflection
SPL
standard

and frankly i would love to anyhting above and *especially* standard as 
loadable extensions instead have it in /usr/bin/php *and* 
/usr/lib64/httpd/modules/libphp7.so compiled beause, well, we run also 
native system services written in PHP which could have a smaller footprint


if ou need some ideas for teh Fedora "rpm.spec" take a look at the 
attachment :-)




Version: 7.1.5

# command 'rpmbuild -bb php.spec --with production' will tune for current hardware while default stays 'sandybridge'
# macro 'php_debug_build' is global (/home/builduser/.rpmmacros) and re-used for pecl-builds while 'debug_build' is local

%global dist  fc%fedora.%(echo $(/usr/bin/date +%Y%m%d.%H%M)).rh
%global phpver7
%global runselftest   0
%global pgo_build 1
%global lto_build 0
%global break_build   0
%global debug_build   0
%global extension_dir %{_libdir}/%{name}/modules

%if %{?_with_production:1}%{!?_with_production:0}
 %global mtune native
 %global rpmsuffix native
 %global php_native_release 1
%else
 %global mtune sandybridge
 %global rpmsuffix sandybridge
 %global php_native_release 0
%endif

%if %php_debug_build
 %global _include_minidebuginfo 1
 %global RH_GCC_DEBUG_OPTION -g3
 %global RH_CONFIGURE_DEBUG_OPTION enable-debug
 %global RH_STRIP_BINARY 0
 %global pgo_build 0
 %global lto_build 0
%else
 %if %debug_build
  %global _include_minidebuginfo 1
  %global RH_GCC_DEBUG_OPTION -g3
  %global RH_CONFIGURE_DEBUG_OPTION enable-debug
  %global RH_STRIP_BINARY 0
  %global pgo_build 0
  %global lto_build 0
 %else
  %global _include_minidebuginfo 0
  %global RH_GCC_DEBUG_OPTION -g0
  %global RH_CONFIGURE_DEBUG_OPTION disable-debug
  %global RH_STRIP_BINARY 1
 %endif
%endif

%if %lto_build
 %global RH_LTO_CONFIGURE_OPTION disable-gcc-global-regs
%else
 %global RH_LTO_CONFIGURE_OPTION enable-gcc-global-regs
%endif

Summary:PHP - CFLAGS: '-m64 -O3 -mfpmath=sse -mavx -msse2avx -march=%{mtune} -mtune=%{mtune} -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 -fopenmp -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 -fno-lto -fuse-ld=gold -fuse-linker-plugin -fprofile-use -Wformat -Werror=format-security -Wno-stack-protector -Wstrict-aliasing -Wa,--noexecstack'
Name:   php
Release:1.%{php_native_release}.%{?dist}.%{rpmsuffix}
License:PHP/Zend/BSD
Group:  Development/Languages
URL:https://secure.php.net/
Source0:php-%{version}.tar.xz
Source1:opcache-zendoptimizer.php
Source2:php-httpd-dummy.conf
Source3:php-disabled-autotests.txt
Source4:php-test-dirs.txt
Source5:php-

Re: [PHP-DEV] [RFC] [Discussion] UUID

[li...@rhsoft.net]

Am 24.05.2017 um 18:35 schrieb Christoph M. Becker:

On 24.05.2017 at 18:25, Remi Collet wrote:


Le 24/05/2017 à 17:57, Levi Morrison a écrit :


I understand the user experience improvement for having a package for UUIDs
in core; I'd like that myself. I just want to know why we haven't discussed
the existing UUID package and made a new one.


I agree here, why a new extension ?

And I also think using system libuuid is better than reinventing the
wheel, and having to maintain a uuid algo, when already maintained by
someone else, which only work on these algo.


What about Windows support?


in times of virtualization and containers i personally would go so far 
and question the need for support windows native at all which would lead 
to a much smaller and cleaner codebase and less maintainance overhead


(not only for PHP)

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

Re: [PHP-DEV] [RFC] [Discussion] UUID

[li...@rhsoft.net]

Am 25.05.2017 um 19:50 schrieb Levi Morrison:

https://wiki.php.net/rfc/uuid#namespace

This is more a general thing. I know from many online conversations,
meetups, and conferences that people would love to see it.


My $0.02 is basically what Nikita Popov has said at some point in the past:

The PHP namespace should be reserved for things that are language
oriented, not stuff shipped by default by PHP. For instance a PHP AST
library would appropriately live in the PHP namespace. A UUID library
which has nothing to do with PHP except that's the language we are
using would not be appropriate there


frankly - we talk about PHP and not some theoretical language

many people use it *because* things like base64_decode(), 
base64_encode(), sha1(), crc32(), crypt(), bin2hex() - what have all 
these samles to do with PHP except that's the language we are using?


no - I and many othes don't want to throw tons of 3rd party code and/or 
external extension in the mix of their applications


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

Re: [PHP-DEV] Parameter type widening RFC

[li...@rhsoft.net]

Am 26.05.2017 um 14:16 schrieb Christoph M. Becker:

On 26.05.2017 at 12:16, Niklas Keller wrote:


2017-05-26 10:35 GMT+02:00 Andrey Andreev :


On Thu, May 25, 2017 at 11:02 PM, Dan Ackroyd 
wrote:


The RFC specifically didn't mention LSPbecause that is separate
from co/contravariance. It's unfortunate for other people to be
throwing the two around at you with a lack of precision.


Perhaps this was the issue ... I was under the impression that LSP was
used as (part of) the motivation for the RFC.

The rest is pretty clear, though thanks for the lengthy explanation. :)


Sorry for the delay and confusion. As Nikita already mentioned, it's a
consequence of LSP, not directly what LSP is about.


Indeed, it is not about LSP, so I suggest to fix the note in UPGRADING[1]


does that also fix the issue https://bugs.php.net/bug.php?id=74394

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

Re: [PHP-DEV] Parameter type widening RFC

[li...@rhsoft.net]

Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:

On 26 May 2017 at 13:23, li...@rhsoft.net  wrote:

does that also fix the issue https://bugs.php.net/bug.php?id=74394



Dear Anonymous,

That "issue" is actually 3 issues.

case 1

class A {
   public function test($a) {}
}
class B extends A {
   public function test(string $a) { }
}

This breaks LSP - because B::test doesn't accept all the things that
A::test can accept and so is unlikely to ever be supported.


and how is that a problem?

A accepts anything
B limits it's inut to a *subset* of "anything"


case 2

class A {
   public function test($a) {}
}

class B extends A {
   public function test($a): string {}
}

This works since return types were introduced.


but is not helpful when you introduce typehints and have to change *all* 
consumers before and at least it should be *consistent* while param 
typehints trigger warnings and return-types fatal errors



case 3

class A {
  public function test($a): string { }
}

class B extends A {
  public function test($a) {}
}

This breaks LSP - anything that is calling A::test would only expect a
string to be returned, but B::test can return anything so is unlikely
to ever be supported.


and how is that a practical problem?

if i add a return-type to A it is *again a subset* of "anything" and can 
be no problem for the extending class and as a cosumer of B i do not 
need anything to know about the parent method



Your tone of words is quite rude and dismissive of other people both
on this list and in the bug reports. That's really not a good way to
persuade people, but particularly so when you seem to not understand
subtle computer science principles but instead want PHP to be
customised for your own way of working.


i understand more than you imagine


If you're installing Composer through an RPM and it's requiring you to
install lots of dependencies, something has gone horribly wrong.
Composer is a standalone phar executable which just needs a normal PHP
environment.


you don't understand what i talk about - when i maintain the complete 
webstack with own packages *no* distribution package ever will work with 
php subpackage dependencies



I'd strongly recommend having another go at using it, and in general
opening yourself up to new ways of doing things rather than being rude
to people who don't share your way of working


i have no need for composer and i just pointed out that people thinking 
"hey there is a package manager named composer and that's the new way 
everyting works" are just plain wrong


PHP is a programming language and the same way as i *never* compromise 
my environment with perl CPAN stuff or "pip" i won't for PHP


people these days seem to think having a ton of package managers 
parallel and going back to days with static linking by using 
flatpak/snap is a long term solution - it is not - but that same people 
also don't maintain servers without reinstall over decades or maintain a 
whole application stack for more the a decade without throwing it all 
alway and start from scratch every few years


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

Re: [PHP-DEV] Parameter type widening RFC

[li...@rhsoft.net]

Am 26.05.2017 um 18:10 schrieb Ryan Pallas:



On Fri, May 26, 2017 at 9:01 AM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:




Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:

On 26 May 2017 at 13:23, li...@rhsoft.net
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> wrote:

does that also fix the issue
https://bugs.php.net/bug.php?id=74394
<https://bugs.php.net/bug.php?id=74394>


Dear Anonymous,

That "issue" is actually 3 issues.

case 1

class A {
public function test($a) {}
}
class B extends A {
public function test(string $a) { }
}

This breaks LSP - because B::test doesn't accept all the things that
A::test can accept and so is unlikely to ever be supported.


and how is that a problem?

A accepts anything
B limits it's inut to a *subset* of "anything"

Because, if I have a function foo(A $a) { $a->test(new Bar()) } that I 
cannot pass B into this function, even though it is a subclass of A. You 
should be able to pass any subclass where its parent is expected, 
allowing parameter narrowing (covariance) would break this.


well, that case is at least a warning

but add a return-type to the parent is a *fatal error* until you update 
the child class and that makes introducing return-types harder than it 
should be


something like "covariance class {}" would be xtremely helpful for all 
that cases where you don't pass objects all day around but have them as 
a *library* in a singletone - in such cases there is no technical 
difference when you add a retrun-type to the parent class then before 
except that what was over years just a "@return integer" is now instead 
of a comment a language construct




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

Re: [PHP-DEV] Parameter type widening RFC

[li...@rhsoft.net]

Am 28.05.2017 um 23:28 schrieb Dan Ackroyd:

On 28 May 2017 at 18:06, Aidan Woods  wrote:

So, if I understand everything here correctly
...
will be equivalent in 7.2? :(



Not equivalent. Adding the Boo param type to an implementation, when
it is only a comment in the parent gives an error.

interface Foo
{
   /*
* @param $Boo, pretty please accept type Boo here
*/
   public function bar( $Boo);
}

class Zot implements Foo {
 public function bar(Boo $Boo) {}
}

Fatal error: Declaration of Zot::bar(Boo $Boo) must be compatible with
Foo::bar($Boo) in %s on line %d


all these things should be just warnings instead fatal errors no matter 
if we talk about params or return-types simply because any sane code 
over years had types in the doc-block comments and now with throw fatal 
errors you just make it only harder move that comment hints to code


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

Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants

[li...@rhsoft.net]

Am 29.05.2017 um 09:48 schrieb Niklas Keller:

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants


Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2

this is nice for a limited timeframe but the wrong approach to begin 
with - it is *not* the business of PHP at all until *explicit* requested 
from the uselrand code to interfer with *anything* in context of the TLS 
handshake


it's the job of the underlying openssl library, how it is built and 
shipped by the distribution becaus ethey you support implicit TLS1.3 and 
a future TLS1.4, don't weaken things like 
https://fedoraproject.org/wiki/Changes/CryptoPolicy and respect san 
econfigured servers which are regulary checked with 
https://www.ssllabs.com/ssltest/




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

Re: [PHP-DEV] [RFC][Post-Discussion]: E_WARNING when using array-index on non valid container

[li...@rhsoft.net]

Am 31.05.2017 um 18:16 schrieb Dan Ackroyd:

On 11 January 2017 at 15:42, David Walker  wrote:

Joe had requested renewed discussion on the accepted RFC[1] and my proposed
PR[2] be brought forward again for implementation discussion, and to come
up with a resolution.

Any
thoughts on a better implementation, or other use cases that need attention
would be appreciated.


Please could you give us an update on the status of the
implementation, and are you still looking for advice on how what would
be needed to complete it?

ps for the record, I just spent an hour today trying to figure out why
code equivalent to

$foo = null;
echo $foo['bar']

wasn't triggering an error, so I hope this can make it for 7.2


because otherwise you couldn't do something like below with a 1-liner 
and so that PHP5.4 feature becomes pretty useless because for a isset() 
you need to store it in a var


function GetKatMaxSort(): int
{
 global $db;
 return (int)$db->fetch_row($db->query('select max(hsort) from ' . 
sql_prefix . 'haupt', 1, 0))[0];

}

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

Re: [PHP-DEV] Class Naming in Core

[li...@rhsoft.net]

Am 03.06.2017 um 10:10 schrieb Tony Marston:
"Dan Ackroyd"  wrote in message 
news:ca+kxmuromvy6vb0ykd6ejqu8askxro2x6f9y5i9+cxfjsj-...@mail.gmail.com...


On 29 May 2017 at 23:13, Fleshgrinder  wrote:

Hey guys!

People are complaining over at Reddit [1]


While the "STD" is slightly humorous, it is unneeded verbosity, and
will lead to pointless arguments in the future of whether other
features in the future should catch the STD name, or whether they
should be directly under PHP. I would recommend not using it.

I don't care about case, though there may be a slight argument that
upper-casing initialisations is the 'standard' in PHP core.


It can only be the "standard" if it has been documented as such and 
everyone follows it. If it was not documented as such from the start of 
the project then it does not qualify. It may have become the most 
commonly used in a selection of alternatives, but that does not give 
anyone the right to now say that it has become the standard and should 
be enforced. That strikes me as being dictatorial and authoritarian, as 
well as requiring large amounts of effort without offering any tangible 
benefits. I'm "consistency" is not a valid benefit in my book


that's fine for your personal book, everywhere else consistency belongs 
to code quality


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

Re: [PHP-DEV] Why hashtable keeps insertion order by default ?

[li...@rhsoft.net]

Am 03.06.2017 um 10:31 schrieb Pawel Por:

AFAIK the hashtable in PHP by default keeps the order in which the
elements are inserted. Could you please write me why it keeps the
insertion order by default ?

Thanks in advance for clarification.
beause when you create a array ['a', 'b']; you don't want to get 
array('b', 'a')


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

Re: [PHP-DEV] Class Naming in Core

[li...@rhsoft.net]

Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be proper 
justification for introducing one now, and I'm afraid that "to be 
consistent" is not a valid argument. What problems are caused by this 
inconsistency? What is the cost, both in core developer time and 
application developer time, to change it? If the benefits are smaller 
than the costs then can the change actually be justified?


seriously, if you don't understand the obvious benefits of consistency 
when a lot of different people have to deal with source code over a long 
period of time likely the discussion with you is pointless and just 
wasted time for everybody involved


in the time you wasted with your mails i typically cleanup inconsistency 
here and there in a project with 25 lines of code which dates back 
to 2003 to make my own life as core-developer and everybody elses easier


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

Re: [PHP-DEV] Class Naming in Core

[li...@rhsoft.net]

Am 05.06.2017 um 10:14 schrieb Tony Marston:

wrote in message news:3cfc0130-e530-64ed-36e8-372b04481...@rhsoft.net...




Am 04.06.2017 um 11:10 schrieb Tony Marston:
If there was never a standard to begin with then there should be 
proper justification for introducing one now, and I'm afraid that "to 
be consistent" is not a valid argument. What problems are caused by 
this inconsistency? What is the cost, both in core developer time and 
application developer time, to change it? If the benefits are smaller 
than the costs then can the change actually be justified?


seriously, if you don't understand the obvious benefits of consistency 
when a lot of different people have to deal with source code over a 
long period of time likely the discussion with you is pointless and 
just wasted time for everybody involved


Seriously, can you explain in words of one syllable the precise benefits 
of such a consistency? Can you measure the benefits? Just because some 
OCD sufferers like consistency is not a good enough reason. I have been 
programming for over 30 years, and in that time I have had to deal with 
both snake_case and CamelCase, and while I personally find that 
snake_case is more readable, especially with names that contain more 
than 3 or 4 words, I have no trouble reading either. Having a mixture of 
styles does not cause a problem (except in the minds of OCD sufferers) 
so IMHO it does not require a solution. Anybody who says that they 
cannot work with a mixture of naming styles is either a liar or Illiterate


it feels like talking with a blind guy about colors
who said "cannot"?

i can mess up my living room and life still goes on
but i won't

i can live without taking a shower over weeks
but i won't

i could work with someone which has a terrible coding style
but i won't

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

Re: [PHP-DEV] Re: Documentation (Doxygen)

[li...@rhsoft.net]

Am 05.06.2017 um 20:16 schrieb Jefferson Gonzalez:
I do not remember all the details, since this was 5 years ago as I wrote 
before, but what I do remember is some of the core developers not 
wanting to saturate the core code with comments, and that the best 
documentation was reading the actual source

please wash me but do not make me wet...

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

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

[li...@rhsoft.net]

Am 06.06.2017 um 12:27 schrieb François Laupretre:
What I am proposing here is very different, as the main objective is to 
dramatically reduce the line count of the core source, without 
significant performance loss. If we had an army of C developers 
maintaining every core extension, maybe we wouldn't need that, but we 
don't (we even have fewer and fewer). What we have instead is thousands 
of lines of C code without any active maintainer. 'phar' is an example 
we talked about recently, but there are many others. Converting some of 
this code to PHP without loosing performance would improve the 
situation, IMO. So, while I agree that 3rd-party extensions may have 
very good reasons to maintain both an extension and a PHP package, 
opposing this for core extensions is very different.


but what is the difference? just because you re-write some code in a 
different programming language don't grow maintainers for the future of 
that code


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

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

[li...@rhsoft.net]

Am 06.06.2017 um 13:06 schrieb François Laupretre:

Le 06/06/2017 à 12:33, li...@rhsoft.net a écrit :


Am 06.06.2017 um 12:27 schrieb François Laupretre:
What I am proposing here is very different, as the main objective is 
to dramatically reduce the line count of the core source, without 
significant performance loss. If we had an army of C developers 
maintaining every core extension, maybe we wouldn't need that, but we 
don't (we even have fewer and fewer). What we have instead is 
thousands of lines of C code without any active maintainer. 'phar' is 
an example we talked about recently, but there are many others. 
Converting some of this code to PHP without loosing performance would 
improve the situation, IMO. So, while I agree that 3rd-party 
extensions may have very good reasons to maintain both an extension 
and a PHP package, opposing this for core extensions is very different.


but what is the difference? just because you re-write some code in a 
different programming language don't grow maintainers for the future 
of that code


Wrong. Moving code from C to PHP reduces the code size, improves 
readability, and dramatically increases the count of potential 
maintainers. How many times did we get messages on the list such as 'I 
would love improving/maintaining the xxx extension but I cannot program 
in C' ?


Let's take the 'phar' extension as an example. The source code is about 
18,000 lines of C. After a quick look, I consider that more than 90 % of 
this code can be rewritten in PHP without loosing ANY performance 
(because this code is used during package creation only). Prior C to PHP 
conversions show that the resulting PHP line count is about 10 % of the 
original. So, we can transform 18,000 lines of very complex C code into 
about 1,500 lines of PHP and probably less than 1,000 remaining lines of 
C. From a maintainability POV, this makes the situation very different. 
After such an operation, phar can attract active maintainers and evolve. 
If it remains as it is now, experience shows that it is frozen for a 
very long time.


looking at the code quality (style, readability, robustness, 
error-handling) of 99% of php userland code out there - which is 
horrible to say it nice -  even if all that is true i still doubt that 
it improves quality in the long term, sometimes it's better working 
things are not maintained then badly maintained


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

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

[li...@rhsoft.net]

Am 06.06.2017 um 15:33 schrieb Rowan Collins:

On 6 June 2017 12:27:16 BST, "li...@rhsoft.net"  wrote:

looking at the code quality (style, readability, robustness,
error-handling) of 99% of php userland code out there - which is
horrible to say it nice -  even if all that is true i still doubt that
it improves quality in the long term, sometimes it's better working
things are not maintained then badly maintained


There is no reason to assume either that we would attract the worst possible PHP 
programmers, or that we currently attract the best possible C programmers. Indeed, it's 
likely that a lot of existing extensions have poor style, lack of robustness, etc, 
because they were written by people "speaking a second language", i.e. PHP 
programmers trying their hand at C.

I'm not even sure your last sentence is true very often - changes to the core 
require changes to extensions, so either the entire core stagnates (in fear of 
breaking things) or extensions get abandoned (because rather than working but 
unmaintained, they are now broken and unmaintained).

There are certainly details to be worked out, but I think the principle of 
making it easier to build and maintain a rich core library is a very good one


that's all nice but in this thread even "composer" was brought once 
again to the game - frankly making composer mandatory will lead to put a 
lot of things require it on a blacklist for a many people because i am 
pretty sure speaking in this context for a silent mass (just the offlist 
responses on other threads where i called composer a red line for me 
with the summary "and i thought i am the only one" are enough to back 
this up)


where will this php scripts stored - how do they deal with openbasedir - 
do you need to place their location in openbasedir while you normally 
avoid to add anything oustide your application there - and so on


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

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

[li...@rhsoft.net]

Am 06.06.2017 um 18:49 schrieb François Laupretre:

Le 06/06/2017 à 17:19, li...@rhsoft.net a écrit :
where will this php scripts stored - how do they deal with openbasedir 
- do you need to place their location in openbasedir while you 
normally avoid to add anything oustide your application there - and so on


Your question proves you didn't even take the time to read the 
'Introduction to PCS' document 
(http://www.tekwire.net/joomla/projects/pcs/intro) before starting to 
complain. Please read it first and you will understand that the PHP 
scripts we are talking about would be embedded into the extension shared 
library file and transparently loaded when needed. composer is also out 
of scope here


the point is that people should stop talking about composer in every 
context like a holy grail because it has *no place* for proper systems 
management and i was not the one calling composer first in this thread


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

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

[li...@rhsoft.net]

Am 07.06.2017 um 16:23 schrieb Pedro Magalhães:

On Wed, Jun 7, 2017 at 4:07 PM, Rowan Collins 
wrote:


you can't simply pass something that *incidentally* changes a
pre-established rule



Hi Rowan,

Would you consider that that is not the case for your own RFC?
https://wiki.php.net/rfc/deprecate-bareword-strings


have you seen any valid uecase for that in the past 15 years which was 
not a typo in a constant name or forgotten quotes?


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

[PHP-DEV] real_path_cache design

[li...@rhsoft.net]

can someone take a look at https://bugs.php.net/bug.php?id=73888

real_path_cache as it is implemented now is pretty worthless when each 
worker maintains it's own cache and clearstatcache() can not work at all 
with that design because the worker which calls clearstatcache() doe sit 
for it's own "instance" of the cache and the others don't know anyhting 
about it


https://github.com/php/php-src/commit/782b84c6d550ac6e695b54070bb0b409cac29f58 
also does more harm than benfits because you waste 4 MB for each worker 
process with a still unpredictable and mostly low hitrate


under growing load with a high number of workers the problem grows, low 
hitrate and clearstatcache() on a just changed file with no effect for 
any of the other worker processes


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

Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

[li...@rhsoft.net]

Am 19.06.2017 um 16:24 schrieb Ivan Enderlin:
Thank you for the RFC. I have a question though. I would like to know 
how is it different from the `goto` language construction?


If I understand it correctly, both the following examples are identical:

try {

 // …

} catch (…) {

 retry;

}

and:

try {

retry:

 // …

} catch (…) {

 goto retry;

}


even if both works the retry-statement is much clearer, especially when 
the code becomes larger than these few lines


Also, what happens if the `try` block keeps failing over and over again: 
This is a non-breakable loop.


well, as for other loops you are responsible at your own to count up a 
$retry_count and stop after N tries


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

Re: [PHP-DEV] Final variables

[li...@rhsoft.net]

Am 29.06.2017 um 04:50 schrieb Kalle Sommer Nielsen:

2017-06-28 20:46 GMT+02:00 David Rodrigues :

The "final" keyworks make a "local scope" variable value "blocked to
rewrite" after instantiate it.
Okay, it sounds like a "const", and it is, but "not as we known it".


I get that, but I still don't understand why you would forcefully need
it to be a variable still then if you know the value is gonna be
constant, of course besides global visibility or in iterations


because constants are expensive in PHP when "define()" is a function 
call and "const" is very limited for no good reason


"no good reason" because if it really would be compile time the 
following won't work and so why can't you use 'const' within a 
if-statement when you in fact can CONCAT two with define() set constant 
which are part of a if-statement themself



if(PHP_SAPI !== 'cli')
{
 define('MY_PHP_SELF', $_SERVER['SCRIPT_NAME']);
 define('rh_serverurl', PROTOCOL_PREFIX . MY_SERVER_NAME . $rh_port);
}
else
{
 define('MY_PHP_SELF', '/' . basename($_SERVER['SCRIPT_NAME']));
 define('rh_serverurl', 'http://localhost');
}
const rh_phpself = rh_serverurl . MY_PHP_SELF;


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

Re: [PHP-DEV] Final variables

[li...@rhsoft.net]

Am 29.06.2017 um 11:08 schrieb Marco Pivetta:
Final is about having immutable data. Immutable doesn't mean that it's a 
system wide constant, it means that it's referentially pure in its scope.


i refered to "why you would forcefully need it to be a variable still 
then if you know the value is gonna be constant" and as long constants 
in PHP are a) very expensive and b) "const" pretends to be compile time 
which is provable wrong with my sample code are terrible to use


in other languages like Visual Basic constants are fast, in PHP they are 
slow, both in define and access


On 29 Jun 2017 11:05 AM, "li...@rhsoft.net <mailto:li...@rhsoft.net>" 
mailto:li...@rhsoft.net>> wrote:




Am 29.06.2017 um 04:50 schrieb Kalle Sommer Nielsen:

2017-06-28 20:46 GMT+02:00 David Rodrigues
mailto:david.pro...@gmail.com>>:

The "final" keyworks make a "local scope" variable value
"blocked to
rewrite" after instantiate it.
Okay, it sounds like a "const", and it is, but "not as we
known it".


I get that, but I still don't understand why you would
forcefully need
it to be a variable still then if you know the value is gonna be
constant, of course besides global visibility or in iterations


because constants are expensive in PHP when "define()" is a function
call and "const" is very limited for no good reason

"no good reason" because if it really would be compile time the
following won't work and so why can't you use 'const' within a
if-statement when you in fact can CONCAT two with define() set
constant which are part of a if-statement themself


if(PHP_SAPI !== 'cli')
{
  define('MY_PHP_SELF', $_SERVER['SCRIPT_NAME']);
  define('rh_serverurl', PROTOCOL_PREFIX . MY_SERVER_NAME . $rh_port);
}
else
{
  define('MY_PHP_SELF', '/' . basename($_SERVER['SCRIPT_NAME']));
  define('rh_serverurl', 'http://localhost');
}
const rh_phpself = rh_serverurl . MY_PHP_SELF;


-- 
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] Final variables

[li...@rhsoft.net]

Am 29.06.2017 um 11:25 schrieb Marco Pivetta:
On Thu, Jun 29, 2017 at 11:19 AM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:


in other languages like Visual Basic constants are fast, in PHP they
are slow, both in define and access


Two things here:

  1. don't ever consider visual basic for any comparison of any sort: 
it's basically (ha!) the worst example of a programming language that I 
can think of before malborge


stop it - many people say the same about PHP

  2. speed is not relevant in this scope: program correctness is. Final 
properties would allow switching value object representations from 
accessor (getter) based logic (extremely slow) to public property based 
(less overhead, also in writing)


in which scope is speed not relevant?

depends on your application, in my scopes i try to avoid expensive 
opcodes and useless function calls, program correctness is a completly 
different thing and it's not one or the other but both


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

Re: [PHP-DEV] Change -> to dot(.)

[li...@rhsoft.net]

Am 06.07.2017 um 08:13 schrieb Khawer.:

In all major programming languages we access object properties and methods
using dot(.).

C#:
Abc Abc = new Abc();
Abc.method();

Java:
Abc Abc = new Abc();
Abc.method();

JavaScript:
var apple = new function() {
 this.name = "Test";
}
alert(apple.name());


Why not to make PHP similar to these languages by allowing to access object
properties and methods using dot(.)


to gain what?


We will still


who is "we"


keep "->" until PHP 8 to maintain backward compatibility


and then force to rewrite every single piece of code out there?
that's a "have a solution and seeking for the problem"

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

Re: [PHP-DEV] Bundled libraries upgrade 'process'

[li...@rhsoft.net]

Am 17.07.2017 um 18:04 schrieb Ryan Jentzsch:

This may be a dumb question...I was under the impression that including the
config switches for the databases such as MySQL, SQLite, Postgres, etc.
that ONLY the PDO bindings are included NOT the database client itself.

Is this the case with the exception of SQLite? In other words is the
version of MySQL that is bundled with PHP also built when I build from
source? Or am I misunderstanding this whole issue?


you need to distinct bewteen "--with-feature" and "--with-fedora=/usr" 
and a sane build normally avoids bundeling as much as possible


with "mysqlnd" you have "libmysqlclient" not in the mix at all for years

# configure build process
./configure \
 --host=x86_64-redhat-linux \
 --build=x86_64-redhat-linux \
 --target=x86_64-redhat-linux \
 --prefix=%{_prefix} \
 --program-prefix= \
 --libdir=%{_libdir}/%{name} \
 --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=%{_bindir}/apxs \
 --with-bz2=shared,%{_prefix} \
 --with-config-file-path=%{_sysconfdir} \
 --with-config-file-scan-dir=%{_sysconfdir}/%{name}.lounge.d \
 --with-curl=shared,%{_prefix} \
 --with-freetype-dir=%{_prefix} \
 --with-gd=shared,%{_prefix} \
 --with-gettext=shared,%{_prefix} \
 --with-iconv=shared \
 --with-imap-ssl=%{_prefix} \
 --with-imap=shared,%{_prefix} \
 --with-kerberos=%{_prefix} \
 --with-layout=GNU \
 --with-libdir=%{_lib} \
 --with-libedit=shared,%{_prefix} \
 --with-libxml-dir=%{_prefix} \
 --with-libzip=%{_prefix} \
 --with-mysql-sock=%{_sharedstatedir}/mysql/mysql.sock \
 --with-mysqli=shared,mysqlnd \
 --with-openssl=shared,%{_prefix} \
 --with-pcre-jit \
 --with-pcre-regex=%{_prefix} \
 --with-pdo-mysql=shared,mysqlnd \
 --with-pic \
 --with-system-ciphers \
 --with-system-tzdata \
 --with-tidy=shared,%{_prefix} \
 --with-zlib=shared \
 --with-zlib-dir=%{_prefix} \
 --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 \
 --%{RH_LTO_CONFIGURE_OPTION} \
 --%{RH_CONFIGURE_DEBUG_OPTION



On Mon, Jul 17, 2017 at 8:12 AM, Dan Ackroyd  wrote:


Hi Internals,

I just investigated an alleged bug related to the SQLite3 extension.
It seems this bug occurs when PHP is compiled with the current bundled
SQLite files, which are a little out of date as they are version:
"3.15.1", date: "2016-11-04".

Listed at https://sqlite.org/changes.html there are multiple versions
that SQLite could be upgraded to.

* 2016-11-28 (3.15.2) - small bugfix upgrade.
* 2017-06-08 (3.19.3) - bigger upgrade that has performance improvements.

Questions:

1. Do we have a process for deciding whether to upgrade bundled libraries?

2. Can anyone see anything in the release notes that would be a
problem for upgrading past 3.15.2 ?

3. Do we have a process for getting feedback from users about whether
a proposed upgrade would cause problems, other than doing the upgrade
and shipping it?

I can't see anything listed in the SQLite release notes that would
cause a problem.but that's obviously not the same as being sure an
upgrade wouldn't cause problems



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

Re: [PHP-DEV] [RFC] samesite cookie implementation

[li...@rhsoft.net]

Am 18.07.2017 um 15:23 schrieb Frederik Bosch | Genkgo:

Hi Andrey,

Thanks for your feedback. If we are going to wait for http_cookie_set, 
then my guess will be that it will take a while before we see samesite 
cookie implemented. While I totally agree there is need for a new 
function with a better API, I fail to see why that would mean we cannot 
have a samesite argument in the set(raw)cookie functions now. The RFC is 
in line with the design of these functions.


With regard to browsers not implementing it, let me quote the currrent 
documentation on the httponly argument. "It has been suggested that this 
setting can effectively help to reduce identity theft through XSS 
attacks (although it is not supported by all browsers), but that claim 
is often disputed." Basically it says that it is not supported by all 
browsers, but provides help reducing XSS attacks. I don't see the 
difference with samesite.


which browser in 2017 does not support 'httponly'?
that was true a decade ago, now that parapgraph in the docs is just FUD


On 18-07-17 12:37, Andrey Andreev wrote:

Hi Frederik,

On Tue, Jul 18, 2017 at 12:11 AM, Frederik Bosch | Genkgo
 wrote:

LS,

Today I finished writing the RFC for implementing same site cookies 
in PHP,

https://wiki.php.net/rfc/same-site-cookie. I am happy to receive your
remarks on the proposal, and improve when necessary.

For those (only) interested in code, have a look at PR # 2613:
https://github.com/php/php-src/pull/2613.

For the record, I am just a messenger in this regard. Someone uploaded a
patch for this feature in bug #72230: 
https://bugs.php.net/bug.php?id=72230.

I just took the opportunity to create a PR and the corresponding RFC.
Credits for the code go to xistence at 0x90 dot nl.

Hopefully, the samesite cookie flag will become a feature of the PHP
language through this RFC!


Unfortunately, all of the cons you've explained in the RFC are very
valid concerns.
I'd rather first see what happens with http_cookie_set() that's being
talked about in another thread currently (I suspect inspired by this)


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

Re: [PHP-DEV] [RFC] samesite cookie implementation

[li...@rhsoft.net]

Am 18.07.2017 um 15:45 schrieb Marco Pivetta:

Hey Andrey,
On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo 
wrote:



LS,

Today I finished writing the RFC for implementing same site cookies in
PHP, https://wiki.php.net/rfc/same-site-cookie. I am happy to receive
your remarks on the proposal, and improve when necessary.

For those (only) interested in code, have a look at PR # 2613:
https://github.com/php/php-src/pull/2613.

For the record, I am just a messenger in this regard. Someone uploaded a
patch for this feature in bug #72230: https://bugs.php.net/bug.php?i
d=72230. I just took the opportunity to create a PR and the corresponding
RFC. Credits for the code go to xistence at 0x90 dot nl.

Hopefully, the samesite cookie flag will become a feature of the PHP
language through this RFC!


The current `setcookie` method has 7 parameters, of which 6 are optional.
This is already a mess, as any default value change introduced for either
forward-compliance or security issue compliance would result in a BC break.

This RFC suggests adding even more parameters (URGH), and increasing the
issue impact.

I had already expressed this issue in https://wiki.php.net/rfc/openssl_aead,
which made the `openssl_encrypt` endpoint a mess to deal with: an
n-dimensional space of optional parameters and possible method behavior
combinations :-P
Imagine all the picturesque ways that people could come up with to do
crypto the wrong way! Fascinating!

Creating a cookie string in userland is trivial, and the `setcookie`
functionality should just be left alone and maybe deprecated, IMO
i don't share your optinion, especially talking about 'should be 
deprecated' where i get the feeling some peoples hobby is deprecate 
working things


comparing cookie params with encryption is hopefully just kidding

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

Re: [PHP-DEV] [RFC] samesite cookie implementation

[li...@rhsoft.net]

Am 18.07.2017 um 16:00 schrieb Marco Pivetta:
On Tue, Jul 18, 2017 at 3:50 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:


i don't share your optinion, especially talking about 'should be
deprecated' where i get the feeling some peoples hobby is deprecate
working things

comparing cookie params with encryption is hopefully just kidding


It could be a "hello world" function - same stuff.

Also, yes, cookies are as security-sensitive stuff as crypto, if not 
often more (since crypto is usually handled at webserver level, and 
direct usage of openssl is more "rare")


how can they than be more security-sensitive within the encryption 
layer but that's not the point: setcookie() even with all it's 
params is easy and clear to use fopr anybody which has a clue what he is 
doing and there is no need to deprecated it nor design a new shiny API 
for it as replacement


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

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[li...@rhsoft.net]

Am 18.07.2017 um 20:39 schrieb Michael Morris:

Personally, I no longer directly use these calls, preferring instead to use
Symfony's HTTP foundation classes. Those in turn are, I understand, in the
process of being converted to implement the common interface outlined here:
http://www.php-fig.org/psr/psr-7/  I would be much more interested in
seeing a bare bones implementation of that agreed on standard in the
language core then seeing something entirely new, especially a band aid
solution


but why do you do this?

looks like these days everybody is using fat frameworks for anything 
like in JavaScript most people think Jquery *is* JavaScript


i must have done something right starting my own cms/framework 
development in 2003 where a typical request takes 0.0015 to 0.0025 
seconds on a 7 years old desktop machine without *any* 3rd party code 
and where you can simply count the function calls of a core system until 
large modules come into play


hence a guest hosting some hundret instances shows 100-500 Mhz on the 
vCenter server and literally you can push out at best 50% of the 
requests the machine could ansser to a internet connection because of 
the additional latencys



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

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[li...@rhsoft.net]

Am 18.07.2017 um 20:56 schrieb li...@rhsoft.net:



Am 18.07.2017 um 20:39 schrieb Michael Morris:
Personally, I no longer directly use these calls, preferring instead 
to use
Symfony's HTTP foundation classes. Those in turn are, I understand, in 
the
process of being converted to implement the common interface outlined 
here:

http://www.php-fig.org/psr/psr-7/  I would be much more interested in
seeing a bare bones implementation of that agreed on standard in the
language core then seeing something entirely new, especially a band aid
solution


but why do you do this?

looks like these days everybody is using fat frameworks for anything 
like in JavaScript most people think Jquery *is* JavaScript


i must have done something right starting my own cms/framework 
development in 2003 where a typical request takes 0.0015 to 0.0025 
seconds on a 7 years old desktop machine without *any* 3rd party code 
and where you can simply count the function calls of a core system until 
large modules come into play


hence a guest hosting some hundret instances shows 100-500 Mhz on the 
vCenter server and literally you can push out at best 50% of the 
requests the machine could ansser to a internet connection because of 
the additional latencys


and no, that "ab" output is not faked

in that case: Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz
a Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz makes 4300/second

Concurrency Level:  250
Time taken for tests:   63.577 seconds
Complete requests:  50
Failed requests:0
Keep-Alive requests:496820
Total transferred:  2092609799 bytes
HTML transferred:   1888721877 bytes
Requests per second:7864.46 [#/sec] (mean)
Time per request:   31.789 [ms] (mean)
Time per request:   0.127 [ms] (mean, across all concurrent requests)
Transfer rate:  32143.07 [Kbytes/sec] received

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

Re: [PHP-DEV] http_cookie_set and http_cookie_remove

[li...@rhsoft.net]

Am 18.07.2017 um 21:02 schrieb Michael Morris:



On Tue, Jul 18, 2017 at 2:56 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto:li...@rhsoft.net>> 
wrote:




Am 18.07.2017 um 20:39 schrieb Michael Morris:

Personally, I no longer directly use these calls, preferring
instead to use
Symfony's HTTP foundation classes. Those in turn are, I
understand, in the
process of being converted to implement the common interface
outlined here:
http://www.php-fig.org/psr/psr-7/
<http://www.php-fig.org/psr/psr-7/>  I would be much more
interested in
seeing a bare bones implementation of that agreed on standard in the
language core then seeing something entirely new, especially a
band aid
solution


but why do you do this?


Because I want to be done in a matter of hours or at most days instead 
of a matter of weeks or months. I've been down the "roll your own" road 
many times. It usually isn't worth it


it is when done right

it takes me 20 seonds to deplay updates on several hosts with hundrests 
of instances - you just need to do it *one* time right


and no: it won't save you days or even hours when you wrap *everything* 
in some framework call when a single native function line can do the 
same with hundret times less costs


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

Re: [PHP-DEV] Minimum MySQL version

[li...@rhsoft.net]

Am 18.07.2017 um 21:37 schrieb Nikita Popov:

I just found out that some of the PDO code contains MySQL version checks
going all the way back to MySQL 3.22.30, which has been released in 2000.

What is the minimum MySQL version we support? can I drop checks for MySQL
3.x and 4.x?
wouldn't it be time to remove all the artefacts before "mysqlnd" and so 
drop any dependency of "libmysql" and/or "libmariadb" these days?


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

Re: [PHP-DEV] php.net website

[li...@rhsoft.net]

Am 19.07.2017 um 19:07 schrieb Mathias Grimm:

I would like to know who is/are "in charge" of the website (
https://github.com/php/web-php).
I think I would like to help improving it a bit


a good start would be http://www.php.net/ also support https:// instead 
one needs to know that https://secure.php.net/ exists and supports 
encryption or at least point the downloads-menu to the encrypted page



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

Re: [PHP-DEV] php.net website

[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

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

[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

[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 <mailto:ni...@php.net> and dmi...@php.net 
<mailto: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 <http://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> 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
<http://gnu.org/licenses/gpl.html <http://gnu.org/licenses/gpl.html>>
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:
<http://www.gnu.org/software/gdb/bugs/
<http://www.gnu.org/software/gdb/bugs/>>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/
<http://www.gnu.org/software/gdb/documentation/>>.
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_

[PHP-DEV] 7.1.8 RC1: compiler warnings

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

[li...@rhsoft.net]

uage=en
 * FETCH 186/399: 
http://localhost:9001/cms/show_content.php?sid=97&show_item=2&language=en
 * FETCH 187/399: 
http://localhost:9001/cms/show_content2.php?s2id=66&language=en
 * FETCH 188/399: 
http://localhost:9001/cms/show_content2.php?s2id=87&language=de
 * FETCH 189/399: 
http://localhost:9001/cms/show_content2.php?s2id=32&language=de
 * FETCH 190/399: 
http://localhost:9001/cms/show_content.php?sid=93&language=en
 * FETCH 191/399: 
http://localhost:9001/cms/show_content2.php?s2id=110&language=en
 * FETCH 192/399: 
http://localhost:9001/cms/show_content2.php?s2id=60&detail_id=1&language=en
 * FETCH 193/399: 
http://localhost:9001/cms/show_content.php?sid=15&language=de
 * FETCH 194/399: 
http://localhost:9001/cms/show_content2.php?s2id=71&language=en
 * FETCH 195/399: 
http://localhost:9001/cms/show_content2.php?s2id=104&language=de
 * FETCH 196/399: 
http://localhost:9001/cms/show_content.php?sid=41&language=en
 * FETCH 197/399: 
http://localhost:9001/cms/show_content2.php?s2id=92&language=en
 * FETCH 198/399: 
http://localhost:9001/cms/show_content2.php?s2id=81&language=en
 * FETCH 199/399: 
http://localhost:9001/cms/show_content.php?sid=102&language=en
 * FETCH 200/399: 
http://localhost:9001/cms/show_content.php?sid=94&language=en
 * FETCH 201/399: 
http://localhost:9001/cms/show_content2.php?s2id=67&language=en
 * FETCH 202/399: 
http://localhost:9001/cms/show_content2.php?s2id=106&language=en
 * FETCH 203/399: 
http://localhost:9001/cms/show_content2.php?s2id=30&language=en
 * FETCH 204/399: 
http://localhost:9001/cms/show_content2.php?s2id=82&language=de
 * FETCH 205/399: 
http://localhost:9001/cms/show_content2.php?s2id=104&language=en
 * FETCH 206/399: 
http://localhost:9001/cms/show_content2.php?s2id=68&language=de
 * FETCH 207/399: 
http://localhost:9001/cms/show_content2.php?s2id=62&language=en
 * FETCH 208/399: 
http://localhost:9001/cms/show_content.php?sid=97&show_item=2&language=de
 * FETCH 209/399: 
http://localhost:9001/cms/show_content.php?sid=91&language=de
 * FETCH 210/399: 
http://localhost:9001/cms/show_content2.php?s2id=107&language=de
 * FETCH 211/399: 
http://localhost:9001/cms/show_content2.php?s2id=78&language=de
 * FETCH 212/399: 
http://localhost:9001/cms/show_content.php?sid=97&show_item=7&language=en
 * FETCH 213/399: 
http://localhost:9001/cms/show_content2.php?s2id=83&language=de
 * FETCH 214/399: 
http://localhost:9001/cms/show_content2.php?s2id=113&language=de
 * FETCH 215/399: 
http://localhost:9001/cms/show_content.php?sid=15&language=en
 * FETCH 216/399: 
http://localhost:9001/cms/show_content2.php?s2id=88&language=de
 * FETCH 217/399: 
http://localhost:9001/cms/show_content2.php?s2id=63&language=en
 * FETCH 218/399: 
http://localhost:9001/cms/show_content2.php?s2id=37&language=de
 * FETCH 219/399: 
http://localhost:9001/cms/show_content2.php?s2id=105&language=de
 * FETCH 220/399: 
http://localhost:9001/cms/show_content.php?sid=103&language=de
 * FETCH 221/399: 
http://localhost:9001/cms/show_content.php?sid=105&language=en
 * FETCH 222/399: 
http://localhost:9001/cms/show_content2.php?s2id=94&language=de
 * FETCH 223/401: 
http://localhost:9001/cms/show_content2.php?s2id=102&language=en
 * FETCH 224/401: 
http://localhost:9001/cms/show_content2.php?s2id=71&language=de
 * FETCH 225/401: 
http://localhost:9001/cms/show_content2.php?s2id=61&language=en
 * FETCH 226/401: 
http://localhost:9001/cms/modules/bildgalerie/webservice.php?list_galleries=1
 * FETCH 227/401: 
http://localhost:9001/cms/show_content2.php?s2id=59&language=en
 * FETCH 228/401: 
http://localhost:9001/cms/show_content2.php?s2id=115&language=en


Am 21.07.2017 um 23:28 schrieb Nikita Popov:
On Fri, Jul 21, 2017 at 1:14 PM, li...@rhsoft.net 
<mailto:li...@rhsoft.net> mailto: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/phpincludes/contentlounge-api/functions.inc.php"?
If this is not publicly available code, can you send the file to
ni...@php.net <mailto:ni...@php.net> <mailto:ni...@php.net
<mailto:ni...@php.net>> and dmi...@php.net
<mailto:dmi...@php.net> <mailto:dmi...@php.net
<mailto:dmi...@php.net>>? (Or reduce the code -- in this case it
should be easy, just delete functions until it stops happening).

Thanks,
Nikita

PS

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

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

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

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

[PHP-DEV] list server broken -> Fwd: ezmlm warning

[li...@rhsoft.net]

what is that for nosense?

"550-Spammy URLs in your message" is for sure *not* a response from our 
mailserver sicne i am the guy who implemented the spamfilter and knows 
every single possible reject message


 Weitergeleitete Nachricht 
Betreff: ezmlm warning
Datum: 24 Jul 2017 21:38:47 -
Von: php-cvs-h...@lists.php.net
An: li...@rhsoft.net

Messages to you from the php-cvs mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

:
76.75.200.58 failed after I sent the message.
Remote host said: 550-5.7.1 mail rejected by policy.  SURBL hit
550-Spammy URLs in your message
550 See http://master.php.net/mail/why.php?why=SURBL


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

[PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[li...@rhsoft.net]

currently i try to optimize our system so that the landing-page if it 
does not contain forms and when no user is logged in could be cached 
with APCu which works fine so far


there is still a early session_start(); and while delay that would be 
probably possible like it's happening currently with database connection 
on-demand


but there are some important things written in $_SESSION which i can't 
delay and the sample below shows that they would get lost in case it's 
not a cache hit

___

if that could work in the way that session_start() keeps the current 
state of $_SESSION if not empty it would be possible to put the 
APCU-Read and if exit($apcu_content); before session_start() which would 
gain another 30% performance


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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[li...@rhsoft.net]

Am 28.07.2017 um 14:48 schrieb Rowan Collins:

On 27 July 2017 18:03:23 BST, "li...@rhsoft.net"  wrote:

if that could work in the way that session_start() keeps the current
state of $_SESSION if not empty it would be possible to put the
APCU-Read and if exit($apcu_content); before session_start() which
would
gain another 30% performance


I think that behaviour would confuse more people than it would help. If 
anything, it should be an error to access $_ SESSION if no session is currently 
open - if there is no session, the array has no meaning. (Arguably, all the 
other superglobals should be read only for the same reason, but that would be a 
huge break now.)


make them readonly would break my whole codebase including autotests and 
code-coverage tools because it is legit to as example fill 
$_SERVER['SERVER_NAME'] with specific informations to define a straight 
behavior when running in cli-test-mode instead wrap every basic thing in 
function calls - at the curretn state a core-cms cache-hit has a total 
of 32 funtion calls including PHP internal ones


hence that 3 bugreport are becoming a MAJOR PROBLEM because the system 
itself is so fast that under load after a short time you get problems 
with dattabase connections and with persistent connections because of 
the third one after the load is gone any strict-typed application jsut 
breaks horrible


https://bugs.php.net/bug.php?id=74971
https://bugs.php.net/bug.php?id=74970
https://bugs.php.net/bug.php?id=74967


If I understand you right, the scenario you describe is "I don't want to start a 
session yet, but if and when I do, I want to put this data into it". It feels like 
that could be adequately handled in userland with a wrapper object (or global var and 
functions if you prefer), which reads to and from $_SESSION when a session is open, but a 
a holding array when it's not yet.


that don't work because at this point you don't know in userland if you 
started a completly new session which should be initialized with values 
for follow-up requests or use the existing values from a previous 
request - at least not without writing ugly code


session_start() knows that and would only need a flag if it is desired 
to bail out as you said above or as for this case init the session with 
specific values



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

Re: [PHP-DEV] session_start() should not reset $_SESSIOn if it's not empty

[li...@rhsoft.net]

Am 28.07.2017 um 16:48 schrieb Andrey Andreev:

Hi,

On Fri, Jul 28, 2017 at 5:45 PM, Sara Golemon  wrote:


ftr; I'd vote in favor of several BC breaking things to do with
autoglobals, among them:

* Make them objects (though ArrayAccess based for less hostile BC breakage)
* Make most of them read-only (offsetGet(), but no offsetSet)
* Make $_SESSION[...] access produce an error or auto-start the session

I've seen too many codebases abuse GPCER vars as a generic storage
location because "globals are bad, but this is good because it doesn't
include the word global".  As a performance issue, the runtime has to
assume autoglobals are inherently volatile and could change on a whim
at any moment (much like $http_response_headers).  Restricting their
mutability would be a win.  The request globals could probably also be
optimized fairly significantly.

If anyone agrees, I'm willing to RFC it.  If not, I'll continue living
with it. :D



Yes, please!


raise a warning when write to $_SESSION without a session_start()

make a implicit autostart - *for sure not* this would only produce 
hidden errors or later warnings when you rely on session params and 
introduce more problems that it solves because clients don't like the 
same cookies ith different params


make POST/GET/SERVER readonly - only when you refactor a 25 line 
code base as well as deplyed code which relies on the framework did the 
right thing with them previously :-)


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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[li...@rhsoft.net]

Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:

2017-07-28 17:11 GMT+02:00 Sara Golemon :

I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D

1. This would be an 8.0 change as it does represent a significant BC change.
2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.


I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to cosindr changes 
breaking a ton of perfect working code


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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[li...@rhsoft.net]

Am 29.07.2017 um 08:47 schrieb Thomas Hruska:
On Fri, Jul 28, 2017 at 11:03 AM, li...@rhsoft.net  
wrote:

make POST/GET/SERVER readonly - only when you refactor a 25 line code
base as well as deplyed code which relies on the framework did the right
thing with them previously :-)


Are you advocating for read-only or leaving them read-write?  I can't tell


how comes?

 Weitergeleitete Nachricht 
Betreff: Re: [PHP-DEV] Changes to SuperGlobals for PHP 8
Datum: Fri, 28 Jul 2017 18:42:16 +0200
Von: li...@rhsoft.net 
An: internals@lists.php.net

Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
> I for one thing it makes a lot of sense to make superglobals
> read-only, writing to them seems more like a hack anyway and should be
> avoided

wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to consider 
changes breaking a ton of perfect working code


 Weitergeleitete Nachricht 
Betreff: Re: [PHP-DEV] session_start() should not reset $_SESSIOn if 
it's not empty

Datum: Fri, 28 Jul 2017 15:37:10 +0200
Von: li...@rhsoft.net 
An: internals@lists.php.net

Am 28.07.2017 um 14:48 schrieb Rowan Collins:
> On 27 July 2017 18:03:23 BST, "li...@rhsoft.net"  
wrote:

>> if that could work in the way that session_start() keeps the current
>> state of $_SESSION if not empty it would be possible to put the
>> APCU-Read and if exit($apcu_content); before session_start() which
>> would
>> gain another 30% performance
>
> I think that behaviour would confuse more people than it would help. 
If anything, it should be an error to access $_ SESSION if no session is 
currently open - if there is no session, the array has no meaning. 
(Arguably, all the other superglobals should be read only for the same 
reason, but that would be a huge break now.)


make them readonly would break my whole codebase including autotests and 
code-coverage tools because it is legit to as example fill 
$_SERVER['SERVER_NAME'] with specific informations to define a straight 
behavior when running in cli-test-mode instead wrap every basic thing in 
function calls - at the curretn state a core-cms cache-hit has a total 
of 32 funtion calls including PHP internal ones


hence that 3 bugreport are becoming a MAJOR PROBLEM because the system 
itself is so fast that under load after a short time you get problems 
with dattabase connections and with persistent connections because of 
the third one after the load is gone any strict-typed application jsut 
breaks horrible


https://bugs.php.net/bug.php?id=74971
https://bugs.php.net/bug.php?id=74970
https://bugs.php.net/bug.php?id=74967

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

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[li...@rhsoft.net]

Am 30.07.2017 um 01:35 schrieb Kalle Sommer Nielsen:

2017-07-29 22:17 GMT+02:00 Stanislav Malyshev :

I've seen scenarios where it is very useful. Sure, you can always build
another layer of indirection and solve it this way, but it's just making
people do more work for no reason. I don't see any problem that would solve.


Sure it seems useful, but I see it more as a hack if you are just
writing to superglobals anyway, if you need to change something you
should do that with your own logic instead.


well, you can do that in your code as you like


If its something simple such as your code assumes $_GET['id'] always
is available, then either write it to a temp variable.


or just leave that decision to the developer


I know many applications nowadays are not written with an excess
amount of globals everywhere, but writing to a global without
explicitly declaring you want to, can cause some hard to debug cases
if one function modifies a global and another assumes an unmodified
value. I'd like to see that gone


frankly are you forced to use it?

PHP has really more important possible improvements than breaking others 
code just because you like to see something gone - in my code i write to 
$_SERVER in a central point to fix the issue that you developers missed 
to standardize what is available there 15 years ago on differnet 
operating systems/SAPI's


hence my code runs since 15 years ago without spit checks around all 
over the codebase and now you "like to see that gone"?


frankly i like the "what can i do to break others code" attitude of some 
people go and if you like to break something for a good reason fix 
inconsistences in the param oders of some database unctions - but better 
don't because i fear your proposed solution would be "why not remove 
anything except PDO"


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

[PHP-DEV] run-tests.php: buggy handling of "-n -c"

[li...@rhsoft.net]

with current 7.2 HEAD runnign the tests in context of rpmbuild triggers 
the warnings in the global errorlog - frankly there is no point loading 
something from the system when with "-n -c" a explicit config which also 
speficifes the extension_dir is given "/usr/lib64/php/modules/phar.so" 
is not from the build but form the installed 7.1.9-dev


because of similar errors i am deleting the openssl tests completly for 
some months now because something tries to load them twice or also from 
the system instead the supplied config while the "php.ini" stes the 
extension_dir and also lists all extension explicitly with 
"extension=name.so"


how can it be that 12000 tests obviously are just fine and random ones 
again and agin have their own picture what configuration and what/if 
extensions have to be loaded?


ulimit -s 32712
unset TZ LANG LC_ALL
export LANG="C" TEST_PHP_EXECUTABLE="$PWD/sapi/cli/php" 
EXTENSION_DIR="$PWD/modules" PHP_INI_SCAN_DIR="$PWD/modules" 
PHP_INI_PATH="$PWD/tmp-php.ini" NO_INTERACTION=1 MALLOC_CHECK_=2 
MYSQL_TEST_HOST="localhost" 
MYSQL_TEST_SOCKET="/var/lib/mysql/mysql.sock" MYSQL_TEST_PORT="3306" 
MYSQL_TEST_USER="php_autotest" MYSQL_TEST_PASSWD="php_autotest" 
MYSQL_TEST_DB="php_autotest" 
PDO_MYSQL_TEST_DSN="mysql:host=localhost;dbname=php_autotest" 
PDO_MYSQL_TEST_SOCKET="/var/lib/mysql/mysql.sock" 
PDO_MYSQL_TEST_USER="php_autotest" PDO_MYSQL_TEST_PASS="php_autotest" 
PDO_MYSQL_TEST_ENGINE="MyISAM"

cp %{SOURCE5} "$PWD/tmp-php.ini" > /dev/null
sed -i "s@__EXTENSION_DIR__@$EXTENSION_DIR@" "$PWD/tmp-php.ini"
$TEST_PHP_EXECUTABLE -n -c $PWD/tmp-php.ini $PWD/run-tests.php -n -c 
$PWD/tmp-php.ini


in Unknown on line 0
These options need to match
PHPcompiled with module API=20170718
Module compiled with module API=20160303
[02-Aug-2017 13:02:57 UTC] PHP Warning:  PHP Startup: readline: Unable 
to initialize module
[02-Aug-2017 13:02:57 UTC] PHP Warning:  PHP Startup: Unable to load 
dynamic library 'phar.so' (tried: /usr/lib64/php/modules/phar.so 
(/usr/lib64/php/modules/phar.so: undefined symbol: spl_ce_Countable), 
/usr/lib64/php/modules/phar.so.so (/usr/lib64/php/modules/phar.so.so: 
cannot open shared object file: No such file or directory)) in Unknown 
on line 0

 in Unknown on line 0
These options need to match
PHPcompiled with module API=20170718
Module compiled with module API=20160303
[02-Aug-2017 13:02:48 UTC] PHP Warning:  PHP Startup: readline: Unable 
to initialize module
[02-Aug-2017 13:02:48 UTC] PHP Warning:  PHP Startup: Unable to load 
dynamic library 'phar.so' (tried: /usr/lib64/php/modules/phar.so 
(/usr/lib64/php/modules/phar.so: undefined symbol: spl_ce_Countable), 
/usr/lib64/php/modules/phar.so.so (/usr/lib64/php/modules/phar.so.so: 
cannot open shared object file: No such file or directory)) in Unknown 
on line 0


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

Re: [PHP-DEV] PHP 8 (or earlier) RFC Proposal

[li...@rhsoft.net]

Am 19.08.2017 um 16:28 schrieb Admin NxPoint:

I would like to know your opinion on an RFC I'm thinking to propose.

I don't have the skills to code this into PHP Core so anyone who would like
to be involved is welcomed.

The RFC would refer to PHP's ability to use either SWAP memory and/or SWAP
Files.

There are some very interesting things that PHP knows how to do, related to
data-processing, filtering, regex and so on, but one of the main blockers
is the "memory limit".

There are servers or situation where memory can't be extended, but where
disk space is available and maybe even fast enough (SSD) to cover that gap.

At this moment PHP doesn't know how to use the SWAP memory from linux, and
there isn't any way to specify a file that could act as one, similar to an
internal PHP SWAP


PHP itself has no business to deal with swap or even know that swap 
exists at all - thats the natural core business of teh underlying 
operating system and userland has not to try outsmart the OS




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

[PHP-DEV] Warning Internal error: wrong size calculation

[li...@rhsoft.net]

after upgrade the first production server from 7.0.22 to 7.1.8 i have 
seen that error twice, likely every time after upgrade said file


is this a known (probably even fixed in trunk) issue in 7.1.x and if not 
am i right that this come from opcache?


Sun Aug 20 19:45:38 2017 (3066): Warning Internal error: wrong size 
calculation: /www/phpincludes/global_mysql_ext.inc.php 
start=0x7feba814c580, end=0x7feba816fc60, real=0x7feba816fc40


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

[PHP-DEV] 7.2.0 beta 3: libtool: Version mismatch error. This is libtool 2.4.6, but the libtool: definition of this LT_INIT

[li...@rhsoft.net]

i saw exactly the same "You should recreate aclocal.m4 with macros from 
libtool 2.4.6" with the first alpha tarball while all the time HEAD, 7.0 
and 7.1 are working fine with the same build-spec

__

that is part of the php.spec - what else should one do to re-create 
everything and why does this issue only happens in released alpha/beta 
versions of 7.2 but never for stable releases nor if you just download 
HEAD from https://git.php.net/?p=php-src.git


# force use of system libtool and regenerate configure scripts
libtoolize --force --copy --quiet
cat `aclocal 
--print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4 > 
build/libtool.m4

touch configure.in
./buildconf --force
__

[builduser@testserver:/rpmbuild/SPECS]$ rpmbuild -bb php.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.jTM60C
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ export LANG=C
+ LANG=C
+ cd /home/builduser/rpmbuild/BUILD
+ rm -rf php-7.2.0
+ /usr/bin/xz -dc /home/builduser/rpmbuild/SOURCES/php-7.2.0.tar.xz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd php-7.2.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #1 (php-realpath-cache-openbasedir.patch):'
Patch #1 (php-realpath-cache-openbasedir.patch):
+ /usr/bin/patch --no-backup-if-mismatch -p1 -b --suffix .realpath --fuzz=0
patching file main/main.c
Hunk #1 succeeded at 1642 (offset -4 lines).
Hunk #2 succeeded at 2245 (offset 9 lines).
+ echo 'Patch #3 (php-71-systzdata.patch):'
Patch #3 (php-71-systzdata.patch):
+ /usr/bin/patch --no-backup-if-mismatch -p1 -b --suffix .systzdata-71 
--fuzz=0

patching file ext/date/lib/parse_tz.c
patching file ext/date/lib/timelib.m4
+ '[' -f /usr/bin/php ']'
+ /usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc
+ '[' -f /usr/bin/php ']'
+ /usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=HYBRID
zend_vm_opcodes.h generated successfully.
zend_vm_opcodes.c generated successfully.
zend_vm_execute.h generated successfully.
+ rm -f TSRM/tsrm_win32.h TSRM/tsrm_config.w32.h Zend/zend_config.w32.h 
ext/mysqlnd/config-win.h ext/standard/winver.h 
main/win32_internal_function_disabled.h main/win95nt.h

+ find . -name '*.[ch]' -exec chmod 644 '{}' ';'
+ xargs rm -f
+ rm -rf ext/openssl/tests/
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.ZQTJDT
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ cd php-7.2.0
+ export LANG=C
+ LANG=C
+ libtoolize --force --copy --quiet
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
+ cat /usr/share/aclocal/libtool.m4 /usr/share/aclocal/ltoptions.m4 
/usr/share/aclocal/ltsugar.m4 /usr/share/aclocal/ltversion.m4 
/usr/share/aclocal/lt~obsolete.m4

+ touch configure.in
+ ./buildconf --force
Forcing buildconf
Removing configure caches
buildconf: checking installation...
buildconf: autoconf version 2.69 (ok)
+ QUIET_FLAG=--quiet
+ export 'CFLAGS=-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'
+ CFLAGS='-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'
+ export 'CC=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-loo

Re: [PHP-DEV] 7.2.0 beta 3: libtool: Version mismatch error. This is libtool 2.4.6, but the libtool: definition of this LT_INIT

[li...@rhsoft.net]

https://git.php.net/?p=php-src.git;a=snapshot;h=799b52e87ff487ae46fabee3715084d1e2c95efe;sf=tgz 
is currently broken the same way


"./configure: line 34382: PHP_GD_TTSTR: command not found" seems to be a 
different bug - however, after tagging the first alpha shape of HEAD 
quality for 7.2 got worse - maybe someone tries to get this wrong again 
- it's just meant as a warning from somebody which built many 
pre-release and HEAD states starting from 2017/02 and just noticed that 
things become worser over time


Am 20.08.2017 um 20:01 schrieb li...@rhsoft.net:
i saw exactly the same "You should recreate aclocal.m4 with macros from 
libtool 2.4.6" with the first alpha tarball while all the time HEAD, 7.0 
and 7.1 are working fine with the same build-spec

__

that is part of the php.spec - what else should one do to re-create 
everything and why does this issue only happens in released alpha/beta 
versions of 7.2 but never for stable releases nor if you just download 
HEAD from https://git.php.net/?p=php-src.git


# force use of system libtool and regenerate configure scripts
libtoolize --force --copy --quiet
cat `aclocal 
--print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4 > 
build/libtool.m4

touch configure.in
./buildconf --force
__

[builduser@testserver:/rpmbuild/SPECS]$ rpmbuild -bb php.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.jTM60C
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ export LANG=C
+ LANG=C
+ cd /home/builduser/rpmbuild/BUILD
+ rm -rf php-7.2.0
+ /usr/bin/xz -dc /home/builduser/rpmbuild/SOURCES/php-7.2.0.tar.xz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd php-7.2.0
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #1 (php-realpath-cache-openbasedir.patch):'
Patch #1 (php-realpath-cache-openbasedir.patch):
+ /usr/bin/patch --no-backup-if-mismatch -p1 -b --suffix .realpath --fuzz=0
patching file main/main.c
Hunk #1 succeeded at 1642 (offset -4 lines).
Hunk #2 succeeded at 2245 (offset 9 lines).
+ echo 'Patch #3 (php-71-systzdata.patch):'
Patch #3 (php-71-systzdata.patch):
+ /usr/bin/patch --no-backup-if-mismatch -p1 -b --suffix .systzdata-71 
--fuzz=0

patching file ext/date/lib/parse_tz.c
patching file ext/date/lib/timelib.m4
+ '[' -f /usr/bin/php ']'
+ /usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc
+ '[' -f /usr/bin/php ']'
+ /usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=HYBRID
zend_vm_opcodes.h generated successfully.
zend_vm_opcodes.c generated successfully.
zend_vm_execute.h generated successfully.
+ rm -f TSRM/tsrm_win32.h TSRM/tsrm_config.w32.h Zend/zend_config.w32.h 
ext/mysqlnd/config-win.h ext/standard/winver.h 
main/win32_internal_function_disabled.h main/win95nt.h

+ find . -name '*.[ch]' -exec chmod 644 '{}' ';'
+ xargs rm -f
+ rm -rf ext/openssl/tests/
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.ZQTJDT
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ cd php-7.2.0
+ export LANG=C
+ LANG=C
+ libtoolize --force --copy --quiet
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
++ aclocal --print-ac-dir
+ cat /usr/share/aclocal/libtool.m4 /usr/share/aclocal/ltoptions.m4 
/usr/share/aclocal/ltsugar.m4 /usr/share/aclocal/ltversion.m4 
/usr/share/aclocal/lt~obsolete.m4

+ touch configure.in
+ ./buildconf --force
Forcing buildconf
Removing configure caches
buildconf: checking installation...
buildconf: autoconf version 2.69 (ok)
+ QUIET_FLAG=--quiet
+ export 'CFLAGS=-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'
+ CFLAGS='-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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 05.09.2017 um 13:36 schrieb Lester Caine:

On 05/09/17 12:18, Yasuo Ohgaki wrote:

I cannot guess people's thought. I appreciated feedback!


With a decent database layer a lot of the validation you are proposing
is already covered but PDO does not help in this area. Adding another
layer that does not integrate with a storage layer is just adding to the
current mess ...


sorry, but you confuse "input validation" which this topic is about with 
something different - input validation and reject bad requests belongs 
some layers on top of any storage and should be done as soon as possible


that should even happen long before you open a database connection at 
all because when you know the request is bad soon enough you won't talk 
to any database, filesystem or whatever storage layer at all



the only question as applicaton developer is how you proceed in which cases

* reject the whole request with a error-message
* reset form-fields where you don't expect an array as input
* reset from-fields with out-of-range input values

here you go:
https://en.wikipedia.org/wiki/Data_validation

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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 05.09.2017 um 15:44 schrieb Lester Caine:

On 05/09/17 14:08, li...@rhsoft.net wrote:

the only question as applicaton developer is how you proceed in which cases

* reject the whole request with a error-message
* reset form-fields where you don't expect an array as input
* reset from-fields with out-of-range input values

here you go:
https://en.wikipedia.org/wiki/Data_validation


When the database layer provides a complete list of fields and
validation rules as part of it's meta data, it is integral to any GOOD
process


your first error is thinking every input is related to databases at all


Copying all that data and manually creating filter rules is
just unnecessary work. In addition much of the VALIDATION is best done
at the browser end, and building that code is a lot easier when there is
a standard validation base across all of the layers!


NO VALIDATION is best done in the browser end because no attacker ever 
will execute your clientside validation code or operate a browser at all



Rejecting crap from hackers that have no format matching the fields on
the browser page is something else and if the data set is corrupt then
yes you can simply skip out before doing anything with it!


and that's what the whole topic is about

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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 05.09.2017 um 18:57 schrieb Lester Caine:

But not at the cost of writing different sets of code to play to each
area where checking SHOULD be done. Stick to a single standard method of
defining the metadata and that already exists in the database layer


ok, to make that point clear:

not every input which needs to be validated or sanitized is *related to 
a database at all* and hence input validation can't be done in the 
database-layer and only there by definition for everything


frankly since 3 weeks our core-application is at a level where the 
database-layer get not loaded at all until inputs are not verfified 
because database stuff is on-demand and 80% of all requests when there 
is some traffic within 80% seconds don't load the database layer because 
of smart caching


form-input is validated, checked against CSRF-tokens, captcha and 
*after* all the validations are fine the database layer becomes part of 
the game - that alone brought again 43% higher requests/second on a 
already highly optimizied codebase



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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 06.09.2017 um 13:52 schrieb Lester Caine:

The likes of ADOdb datadict are still used as a base for metadata in
projects, but PDO destroyed the standardisation that used to exist by
spawning a number of competing wrappers. https://github.com/ADOdb/ADOdb
has evolved from a private project to being supported by it's own
community and is worth reconsidering as a proper cross database standard
to build on. Validation rules simply build on that base


frankly - why don't you realize that input validation DOES NOT turn 
around databases at all - databases and SQL injection are *just one* 
subset of it and not every application works with databases at all


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

Re: [PHP-DEV] [RFC] Match expression

[li...@rhsoft.net]

Am 10.09.2017 um 21:16 schrieb Theodore Brown:

On Sunday, September 10, 2017 12:45 PM Rowan Collins  
wrote:


Would it be possible to add an optional `$strict` parameter to
switch? E.g.
```
switch ($i, true) {


I'd very much prefer a "strict switch ($i) { ... }" over a second parameter.


What do either of you think of my "switch-use" proposal, which would spell this as 
"switch ($i) use (===)"?


That seems more complicated and confusing than either of the other options. 
Normally `use()` is for inheriting variables in anonymous functions.



where did you see `use()` in the proposed SYNTAX?
hint: it's not there

it's just "strict switch" versus "switch"

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

Re: [PHP-DEV] [RFC] Match expression

[li...@rhsoft.net]

Am 10.09.2017 um 21:25 schrieb Ryan Pallas:



On Sep 10, 2017 1:23 PM, "li...@rhsoft.net <mailto:li...@rhsoft.net>" 
mailto:li...@rhsoft.net>> wrote:




Am 10.09.2017 um 21:16 schrieb Theodore Brown:

On Sunday, September 10, 2017 12:45 PM Rowan Collins
mailto:rowan.coll...@gmail.com>> wrote:

Would it be possible to add an optional `$strict`
parameter to
switch? E.g.
```
switch ($i, true) {


I'd very much prefer a "strict switch ($i) { ... }" over
a second parameter.


What do either of you think of my "switch-use" proposal,
which would spell this as "switch ($i) use (===)"?

That seems more complicated and confusing than either of the
other options. Normally `use()` is for inheriting variables in
anonymous functions.


where did you see `use()` in the proposed SYNTAX?
hint: it's not there

it's just "strict switch" versus "switch"

Rowan's suggestion included use


the whole switch discussion is broken by design
with "raise an error if cases are mixed (case 'a' and case 1 und the same 
switch) and also raise an error in a case libe below when $a is anything 
else then int


there is reall yno syntax sugar needed - the first statement of the file 
contains the intention of the developer and yes i migrated a 25 LOC 
codebase stared in 2003 with PHP4 to PHP7 with strict types for every 
single file


switch($a)
{
 case 1: ..; break;
 case 2: ..; break;
}

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

Re: [PHP-DEV] [RFC] Match expression

[li...@rhsoft.net]

Am 10.09.2017 um 22:35 schrieb Rowan Collins:

On 10/09/2017 20:35, li...@rhsoft.net wrote:
with "

strict_types does not currently have any effect on comparisons anywhere, 
and nor is it likely ever to do so. It is a very specific option, not a 
broad set of behaviours like "use strict" in JS or Perl.


in case of a normal comparison you have !== and === to make it explicit

raise an error if cases are mixed (case 'a' and case 1 under  the same 
switch)


It's interesting that the behaviour you think is obvious is completely 
different to what I think of: if the author of the code has put both 
case 42 and case '42' in the switch statement, the "strict" 
interpretation in my mind would be that both branches are reachable, as 
though tested with an "===" operator (whereas currently the second would 
never be selected, because no value =='42' that doesn't also ==42).


yes, for non-strict code that's fine

and also raise an error in a case like below when $a is  anything else 
then int


I guess this explains the different direction you're coming from: what 
you want could perhaps be termed a "strongly typed switch statement", 
where both input and case values are checked as soon as possible for 
being of some specified type.


yes, that's what i expect from declare(strict_types=1); wherever it is 
possible for several reasons


* as developer i like fail early and raise a clear exception
* in the best case even at compile time and not 3 days later at runtime
* it makes code often more secure over time when it points
  out missing input validation and from where a bad value comes
  instead burry a error where it triggers the exception
* it enables optimizations like 7.1 got a lot
* it even may help a future JIT to optimize

due change every code i wrote to strict-types and enhance every function 
to type-hints and return types i found a ton of hidden probably bugs and 
especially fuzzying points out code weakness


The logical syntax for that would probably be an explicit type in the 
switch statement somewhere, like this:


switch(int $a)
{
  case 1: ..; break;
  case 2: ..; break;
}


i like that!

Although an obvious question would be why switch gets such a version, 
and what other language constructs should follow suit.


well, you have to start somewhere and the start was done with 7.0 for 
function params and return types, switch is an obvious  place that could 
be enhanced and the syntax above is 100% consistent to function params


it's not only consistent in the syntax, it's also consistent in behavior 
meaning in no-strict-mode make a implicit type cast and it's not a new 
syntax element


currently i have no other language constrcuts in mind but i think 
starting here could lead in people point out other places where it makes 
sense and since it's completly opt-in it don't break any existing code


ok, i have one in mind
foreach($arr as int $x)

raise a runtime error when you expect a array with only numbers and the 
comes '42' and in strict-mode do a consistent implicit cast in 
non-strict where you can be sure in both cases that you deal with a int 
within the loop


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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 11.09.2017 um 23:07 schrieb Yasuo Ohgaki

On Tue, Sep 12, 2017 at 12:22 AM, Stephen Reay 

So, you still didn’t actually provide an example. I *guess* you’re talking
about character class validation or something else equally “simple”,
because I can’t imagine what else would be a common enough case that you’d
want to have built-in rules for, and that you wouldn’t internally use
RegExp to test anyway.


Your request is like "Devil's Proof". Example code that cannot do things
with existing API cannot exist with meaningful manner. It can be explained
why it cannot, though. Try what "validate" string validator can do,
Then you'll see.

There is no STRING validation filter currently. This fact alone,
it could be said "filter cannot do string validation currently".

List of problems in current validation filter
but you still fail to explain why in the world you don#t try to enhance 
the existing filter functions instead invent a new beast leading finally 
to have the existin filter functions and your new stuff which share the 
same intention


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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 11.09.2017 um 23:39 schrieb Yasuo Ohgaki:
On Tue, Sep 12, 2017 at 6:35 AM, li...@rhsoft.net 
but you still fail to explain why in the world you don#t try to

enhance the existing filter functions instead invent a new beast
leading finally to have the existin filter functions and your new
stuff which share the same intention


Why don't you read previous RFC and the vote result?
https://wiki.php.net/rfc/add_validate_functions_to_filter


and why do you not take the contra arguments against how do you think 
things should be done into your considerations and believe bikeshed it 
with a different name will achieve anything?


it's basially the same as your hash_hkdf() related stuff - you just 
ignore everybody and cntinue to ride a dead horse up to a level where 
even pure readers of the internals list just have enough and only think 
"stop it guy"




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

Re: [PHP-DEV] A validator module for PHP7

[li...@rhsoft.net]

Am 11.09.2017 um 23:49 schrieb Yasuo Ohgaki:

but you still fail to explain why in the world you don#t try to
enhance the existing filter functions instead invent a new beast
leading finally to have the existin filter functions and your
new stuff which share the same intention


Why don't you read previous RFC and the vote result?
https://wiki.php.net/rfc/add_validate_functions_to_filter



I'm a bit surprised by the fact there are "filter improvement" supporters.
You should have participated in the previous RFC discussion


and i am suprise that you act *that* stubborn and obviously think when 
you give the bike a new name someone will buy it instead really consider 
the contras of previous proposals


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 15.09.2017 um 11:12 schrieb Tony Marston:
I am not asking the world to slow down because I am too lazy to change. 
I am arguing that case insensitive software has been around for many 
decades, and for some people to advocate for its removal just because 
they don't have the brain power to come up with a proper solution for a 
minor glitch that affects only a small number of languages I find 
unacceptable. A competent programmer would fix the problem that affects 
the few without removing a feature that the many are used to


and a competent programmer using PHP as programming language would not 
define a funtion do_something() and write "Do_Something", 
"do_Something", "DO_something" all over his codebase


the problem which makes such a change dramatic is the poor code quality 
of most projects and as i remeber you even fighted some months ago that 
a consistent coding style within a project is nothing you care about and 
that explains how you argue here very well


 Weitergeleitete Nachricht 
Betreff: Re: [PHP-DEV] Class Naming in Core
Datum: Mon, 5 Jun 2017 09:14:47 +0100
Von: Tony Marston 
An: internals@lists.php.net

Seriously, can you explain in words of one syllable the precise benefits 
of such a consistency? Can you measure the benefits? Just because some 
OCD sufferers like consistency is not a good enough reason. I have been 
programming for over 30 years, and in that time I have had to deal with 
both snake_case and CamelCase, and while I personally find that 
snake_case is more readable, especially with names that contain more 
than 3 or 4 words, I have no trouble reading either. Having a mixture of 
styles does not cause a problem (except in the minds of OCD sufferers) 
so IMHO it does not require a solution. Anybody who says that they 
cannot work with a mixture of naming styles is either a liar or Illiterate.


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 15.09.2017 um 11:25 schrieb Tony Marston:
You are missing a third option - Microsoft languages are 
case-preserving. This is where the IDE ensures that every use of a word 
is automatically switched to the case used in its original definition. 
This makes it impossible to use the same word with a different case.


a sane IDE for PHP does exactly the same for many many years if you 
don't insist to change it manually - when you manage that you functions 
are written all over your codebase with different uppercase/lowercase 
the problem is looking at you from a mirror every morning


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 15.09.2017 um 16:15 schrieb Tony Marston:
Can you show me any language where a single character has multiple 
alternatives when switching case?


http://cdn.webfail.com/upl/img/07181c2ca27/post2.jpg
_

german:  Sie ist wirklich gut zu Vögeln
english: she is really nice to birds

german:  Sie ist wirkich gut zu vögeln
english: she is really nice to fuck
_

german:  Ich wünschte er wäre Dichter!
english: i wish he would be a poet

german:  Ich ünschte er wäre dichter!
english: i wish he would be more drunken
_

and now stop it!

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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 15.09.2017 um 16:38 schrieb Tony Marston:

wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c...@rhsoft.net...


Am 15.09.2017 um 11:12 schrieb Tony Marston:
I am not asking the world to slow down because I am too lazy to 
change. I am arguing that case insensitive software has been around 
for many decades, and for some people to advocate for its removal 
just because they don't have the brain power to come up with a proper 
solution for a minor glitch that affects only a small number of 
languages I find unacceptable. A competent programmer would fix the 
problem that affects the few without removing a feature that the many 
are used to


and a competent programmer using PHP as programming language would not 
define a funtion do_something() and write "Do_Something", 
"do_Something", "DO_something" all over his codebase


While that may be "uncool" or even "inconsistent" it does not cause a 
genuine problem. But you seem to be supporting a change which would be 
worse than uncool, it would be downright horrific. No human language 
that I know of allows a word to change its meaning just by changing the 
case of one or more characters


i brought you samples of german where the meanining of the same word 
changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which 
goes from "nice to birds" to "nice to fuck"


and this standard behaviour was echoed 
in all the computer systems that I have used since the 1970s. The fact 
that I can create a function called do_something() and later refer to it 
as either Do_something(), do_Something() or even Do_SomeThing() may be 
annoying but it is irrelevant. Do you realise how many problems it would 
cause if each change in case pointed to a totally different function?


only when one is so short-sighted as you act

it's not rocket science at compile time throw a error that you are not 
allowed to define foo() and Foo() in the same software which has no 
runtime costs and after that you may even have less runtime costs 
because all the case-insensitive handling can be skipped


and well, for the time of deprecation the compiler code with finally 
throws errors can issue the warnings with file and line - i assure you 
that going to fix that warnings takes less time than the whole 
discussion with you over the last days from several people


Would you support anyone who proposed adding a series of functions to 
PHP core or an extension where every function used exactly the same 
words but in a different case?

see above - just because you assume it's rocket scienece doesn't mean it is

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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 15.09.2017 um 16:58 schrieb Tony Marston:

wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf3...@rhsoft.net...


Am 15.09.2017 um 11:25 schrieb Tony Marston:
You are missing a third option - Microsoft languages are 
case-preserving. This is where the IDE ensures that every use of a 
word is automatically switched to the case used in its original 
definition. This makes it impossible to use the same word with a 
different case.


a sane IDE for PHP does exactly the same for many many years if you 
don't insist to change it manually - when you manage that you 
functions are written all over your codebase with different 
uppercase/lowercase the problem is looking at you from a mirror every 
morning


How many IDEs out there for PHP? What percentage of them support case 
preserving? Zend Studio didn't when I used it. PHPEd doesn't


i need to see one which don't make autocompletion with preserved case 
and if you don't use it because you like typos in general your fault


again: it's no rocket science to throw at compile time deprecation 
warnings years before a final change is planned and so for sloppy legacy 
code you hav enot more to do than read your error logs


after i switched every piece of code i write the last 15 years tpo 
strict-types, typhe-hints and return-types everywhere while also write a 
complete autotest suite you can't tell me it costs more time to fix such 
case warnings by read the log and it would take longer as all your 
discussions - so why don't you stop it?



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

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[li...@rhsoft.net]

Am 15.09.2017 um 19:20 schrieb ilija.tov...@me.com:

Hi!

The `extract` function takes an associative array and puts it into the local 
symbol table.
http://php.net/manual/en/function.extract.php

```
$array = [
     ‘foo’ => ‘foo’,
     ‘bar’ => ‘bar’,
];

extract($array);

print $foo; // "foo"
```

As a second parameter the `extract` function takes some options to make this 
function less dangerous, like `EXTR_SKIP` that prevents an existing local 
variable of being overwritten. There’s a few more options, go ahead and take a 
look at the documentation. `EXTR_OVERWRITE` is the default one though. You can 
also pass a prefix for the variable names as a third argument.

I seriously doubt the usefulness of this function


then don't use it - who are you proposing remove functionality because 
you don't use it - fine, nobody forces you to do so -  a foreach() 
replacement would miss EXTR_OVERWRITE - this whole thread is a "have 
solution, looking for a problem"


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

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[li...@rhsoft.net]

Am 15.09.2017 um 19:38 schrieb ilija.tov...@me.com:

I can see your argument. The reasoning behind it is that a function in the 
standard library should not encourage unsafe code. Admittedly, since this 
function is rarely used


who do you think you are that you can qualify this?
breaking news: there is code outside the s*itlab/s*ithub world!

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

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[li...@rhsoft.net]

Am 15.09.2017 um 20:27 schrieb Arvids Godjuks:

well, basically, none. Results are from a Q6600 machine and under windows,
so your mileage probably gonna be quite better :)


well, and now implement the EXTR_SKIP in PHP code - that becomes a ugly 
piece of code and that only because someone likes to remove a already 
existing function nobody is forced to use?


sadly i am not allowed to say what i think in public...


C:\Users\psihius\Documents\web>php -v
PHP 7.1.5 (cli) (built: May  9 2017 19:48:36) ( NTS MSVC14 (Visual C++
2015) x64 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
C:\Users\psihius\Documents\web>php -d memory_limit=-1 test.php
6.884626150131226 - Creating arrays
2.035606861114502 - foreach
2.128609180450439 - extract

The code:

define('ITERATIONS', 1000);

$__time = microtime(true);

$__array = $__array2 = [];
for ($__i = 0; $__i < ITERATIONS; ++$__i) {
 $__array['a'.$__i] = $__i;
 $__array2['b'.$__i] = $__i;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;

$__time = microtime(true);
foreach ($__array as $__key => $__variable) {
 $$__key = $__variable;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;

$__time = microtime(true);
foreach ($__array2 as $__key => $__variable) {
 $$__key = $__variable;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;



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

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[li...@rhsoft.net]

Am 16.09.2017 um 11:44 schrieb ilija.tov...@me.com:

Dude, calm down.


dude when people have no other hobbies than think about removing 
functionality for *no gain*



This was a request for feedback


then you should withstand the feedback!
why don't you spend your time for *add* features instead cripple things?

As other people have pointed out before 
it may not be the best idea to remove it since there’s no good way to 
write the equivalent code in PHP. No reason to be rude.


On 16 Sep 2017, 11:42 +0200, li...@rhsoft.net , wrote:



Am 15.09.2017 um 20:27 schrieb Arvids Godjuks:
well, basically, none. Results are from a Q6600 machine and under 
windows,

so your mileage probably gonna be quite better :)


well, and now implement the EXTR_SKIP in PHP code - that becomes a ugly
piece of code and that only because someone likes to remove a already
existing function nobody is forced to use?

sadly i am not allowed to say what i think in public...


C:\Users\psihius\Documents\web>php -v
PHP 7.1.5 (cli) (built: May 9 2017 19:48:36) ( NTS MSVC14 (Visual C++
2015) x64 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
C:\Users\psihius\Documents\web>php -d memory_limit=-1 test.php
6.884626150131226 - Creating arrays
2.035606861114502 - foreach
2.128609180450439 - extract

The code:

define('ITERATIONS', 1000);

$__time = microtime(true);

$__array = $__array2 = [];
for ($__i = 0; $__i < ITERATIONS; ++$__i) {
$__array['a'.$__i] = $__i;
$__array2['b'.$__i] = $__i;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;

$__time = microtime(true);
foreach ($__array as $__key => $__variable) {
$$__key = $__variable;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;

$__time = microtime(true);
foreach ($__array2 as $__key => $__variable) {
$$__key = $__variable;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 16.09.2017 um 11:36 schrieb Tony Marston:

wrote in message news:bd24d73e-4999-ffd9-ce03-6b7629037...@rhsoft.net...
after i switched every piece of code i write the last 15 years tpo 
strict-types, typhe-hints and return-types everywhere while also write 
a complete autotest suite you can't tell me it costs more time to fix 
such case warnings by read the log and it would take longer as all 
your discussions - so why don't you stop it?


Just because you disagree with what I have to say does not mean that you 
can tell me to stop saying it. If you want me to accept that you can 
have a different opinion then you should extend the same courtesy to me.
you statet your opinion often enough as you did in the thread where you 
explained us that code consistency don't matter for you - in both cases 
nobody agreed


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

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[li...@rhsoft.net]

Am 16.09.2017 um 13:48 schrieb Marco Pivetta:
"then don't use it" worked great for `register_globals` and 
`magic_quotes`. Not saying it is the same here, but you really ought to 
have a bit of a mentality adjustment


so when it is not the same why do you mention it?

there is a difference between a config option which can change on each 
and every machine at every point in time and completly and then 
completly change behavior or a explicit function call


what is the next step in your logic?

remove foreach() because one could do foreach($_REQUEST as $key=>$var) 
to emulate extract() after you took it away?


PHP is a programming language and not a office software - it depends on 
the usecase and source of data to qualify a operation as safe and it's 
completly the responsibility of the programmer using a programming 
language, not yours


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

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

[li...@rhsoft.net]

Am 19.09.2017 um 11:24 schrieb Tony Marston:
If the single character  "ß" represents two "s" characters joined 
together, then the uppercase equivalent should also be a single 
character which looks like two "S" characters joined together. If it is 
not possible to write code which deals with these exceptions, then one 
alternative would be to remove these exceptions


remove from where?
from the reality?

have fun, it becomes even more complexer and currently it's in 
discussion where to place the uppercase on a keyboard

https://en.wikipedia.org/wiki/%C3%9F#Capital_form

> If the single character "ß" represents two "s"

no, until short ago there where just no uppercase one and that's only 
about german - you still missed *to prove* "Removing case insensitivity 
completely is not a proper solution as it removes a feature that we 
humans have been used to for decades" since i know nobody right in his 
mind which writes inconsistent code where this is a real world problem 
and if someone writtes "my_function", "MY_function" and "my_Function" in 
his code and don#t stop that nosnese he simply get fired





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