[PHP-DEV] Re: Changes to when OPcache initialises

[Dmitry Stogov]

Looks fine.


On 12/24/18 12:17 AM, Derick Rethans wrote:
> Hi,
> 
> VLD is not a zend extension, so gets loaded/initialised later anyway.
> And it seems your hint with post_startup works. I'd appreciate if you
> could have a look at my change though:
> 
> https://github.com/xdebug/xdebug/commit/3ef3c63ffc831426a45439dbf8b56b998f84d5b1
> 
> cheers,
> Derick
> 
> On Mon, 17 Dec 2018, Dmitry Stogov wrote:
> 
>> Hi Derick,
>>
>>
>> First, check why VLD works out of the box.
>>
>> At second, you may plug into post_startup hook to reassign zend_compile 
>> after opcache.
>>
>>
>> Thanks. Dmitry.
>>
>> 
>> From: Derick Rethans 
>> Sent: Saturday, December 15, 2018 10:01:37 PM
>> To: Dmitry Stogov
>> Cc: Nikita Popov; PHP Developers Mailing List
>> Subject: Changes to when OPcache initialises
>>
>> Hi!
>>
>> I am working on making Xdebug work properly with PHP 7.3, and over the
>> last week I have been tearing my hair out as to why Xdebug's view of
>> opcodes was no longer showing the opcodes that OPcache had
>> modified/optimised. In PHP 7.2, the order in which you load Xdebug and
>> OPcache made a difference.
>>
>> OPcache optimises out line 6, which has dead code:
>>
>>1 >2
>>3 try
>>4 {
>>5 throw new Exception();
>>6 echo strlen( "Revenge is a dish best served cold.\n" );
>>7 }
>>8 catch(Exception $e)
>>9 {
>>   10 }
>>   11
>>   12 echo strlen( "The fire is always hotter on someone elses face." ), "\n";
>>   13 ?>
>>
>>
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.2.13/bin/php  
>> -n -dzend_extension=opcache.so  -d "zend_extension=xdebug.so" -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(4) {
>>[5] =>
>>int(1)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>>
>> [GIT: issue1598-no-code-coverage-with-opcache][PHP: 7.2.13  ]
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.2.13/bin/php  
>> -n  -d "zend_extension=xdebug.so" -dzend_extension=opcache.so -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(5) {
>>[5] =>
>>int(1)
>>[6] =>
>>int(-2)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>>
>> Where as with PHP 7.3.0, they both show the *unoptimised* version:
>>
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.3.0/bin/php  
>> -n -dzend_extension=opcache.so  -d "zend_extension=xdebug.so" -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(5) {
>>[5] =>
>>int(1)
>>[6] =>
>>int(-2)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>> [GIT: issue1598-no-code-coverage-with-opcache][PHP: 7.2.13  ]
>> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.3.0/bin/php  
>> -n  -d "zend_extension=xdebug.so" -dzend_extension=opcache.so -d 
>> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
>> -dvld.active=1 -f 
>> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
>> 48
>> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
>> array(5) {
>>[5] =>
>>int(1)
>>[6] =>
>>int(-2)
>>[8] =>
>>int(1)
>>[12] =>
>>int(1)
>>[14] =>
>>int(1)
>> }
>>
>> Curiously, vld, would always show the right (optimised) opcodes:
>>
>> filename:   /home/derick/dev/php/derickr-xdebug/tests/bug00213.inc
>> function name:  (null)
>> number of ops:  12
>> compiled vars:  !0 = $e
>> line #* E I O op   fetch  ext  return  
>> operands
>> -
>> 5 0  E >   EXT_STMT
>>   1NEW  $1  
>> :-5
>>   2EXT_FCALL_BEGIN
>>   3DO_FCALL  0
>>   4EXT_FCALL_END
>>   5  > THROW 0  
>> $1
>> 8 6  E > > CATCH
>> 'Exception', !0
>>12 7>   EXT_STMT
>>   8ECHO 
>> 48
>>   9EXT_STMT
>>  10ECHO 
>> 

[PHP-DEV] Re: Changes to Traits in master/PHP 7.4

[Dmitry Stogov]

Done. Thanks for noticing this.

On 12/24/18 12:24 AM, Derick Rethans wrote:
> Hi Dmitry,
> 
> You removed ADD_TRAIT and BIND_TRAITS in
> https://github.com/php/php-src/commit/67397970b25d03254f000c36a73204720475b324
> — could you please add that to UPGRADING.INTERNALS?
> 
> cheers,
> Derick
> 

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

[Dmitry Stogov]

On 12/22/18 1:32 PM, Nikita Popov wrote:
> On Thu, Dec 20, 2018 at 4:13 PM Dmitry Stogov  > wrote:
> 
> Hi internals,
> 
> 
> The FFI RFC is turned into voting state.
> 
> 
> https://wiki.php.net/rfc/ffi
> 
> 
> There were very few minor changes since the initial proposal, e.g.
> renaming FFI:array_type() into FFI::arrayType()
> 
> 
> Thanks. Dmitry.
> 
> 
> My main concern here is that this is a very new extension and I think 
> that apart from you barely anyone had a chance to actually implement 
> something based on it and gain experience using the proposed API. 
> Bundling an extension with PHP means that the API becomes frozen in time 
> and it becomes very hard to change anything.
> I think that having FFI support is important, but I'm afraid that once 
> we bundle this extension and it will see more usage, it will quickly 
> turn out that the API needs to change to make it easier to use or 
> accommodate more use-cases.
> 
> My other concern is platform support. FFI is by nature a rather platform 
> dependent. The RFC says that the extension is currently tested on Linux 
> and Windows. It would be great if someone using such a system can 
> confirm whether it also works on OSX and FreeBSD, so we at least have 
> coverage of the major platforms.
> 


The API almost completely repeats LuaJIT and Python CFFI (that are 
stable). Something might need to be improved, of course, but only in 
case the extension is going to be widely used.

The main reason, I like to have this in core - future integration with JIT.

Thanks. Dmitry.

> Nikita

[PHP-DEV] Changes to Traits in master/PHP 7.4

[Derick Rethans]

Hi Dmitry,

You removed ADD_TRAIT and BIND_TRAITS in 
https://github.com/php/php-src/commit/67397970b25d03254f000c36a73204720475b324 
— could you please add that to UPGRADING.INTERNALS?

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

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

[PHP-DEV] Re: Changes to when OPcache initialises

[Derick Rethans]

Hi,

VLD is not a zend extension, so gets loaded/initialised later anyway. 
And it seems your hint with post_startup works. I'd appreciate if you 
could have a look at my change though:

https://github.com/xdebug/xdebug/commit/3ef3c63ffc831426a45439dbf8b56b998f84d5b1

cheers,
Derick

On Mon, 17 Dec 2018, Dmitry Stogov wrote:

> Hi Derick,
> 
> 
> First, check why VLD works out of the box.
> 
> At second, you may plug into post_startup hook to reassign zend_compile after 
> opcache.
> 
> 
> Thanks. Dmitry.
> 
> 
> From: Derick Rethans 
> Sent: Saturday, December 15, 2018 10:01:37 PM
> To: Dmitry Stogov
> Cc: Nikita Popov; PHP Developers Mailing List
> Subject: Changes to when OPcache initialises
> 
> Hi!
> 
> I am working on making Xdebug work properly with PHP 7.3, and over the
> last week I have been tearing my hair out as to why Xdebug's view of
> opcodes was no longer showing the opcodes that OPcache had
> modified/optimised. In PHP 7.2, the order in which you load Xdebug and
> OPcache made a difference.
> 
> OPcache optimises out line 6, which has dead code:
> 
>   12
>   3 try
>   4 {
>   5 throw new Exception();
>   6 echo strlen( "Revenge is a dish best served cold.\n" );
>   7 }
>   8 catch(Exception $e)
>   9 {
>  10 }
>  11
>  12 echo strlen( "The fire is always hotter on someone elses face." ), "\n";
>  13 ?>
> 
> 
> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.2.13/bin/php  
> -n -dzend_extension=opcache.so  -d "zend_extension=xdebug.so" -d 
> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
> -dvld.active=1 -f 
> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
> 48
> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
> array(4) {
>   [5] =>
>   int(1)
>   [8] =>
>   int(1)
>   [12] =>
>   int(1)
>   [14] =>
>   int(1)
> }
> 
> [GIT: issue1598-no-code-coverage-with-opcache][PHP: 7.2.13  ]
> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.2.13/bin/php  
> -n  -d "zend_extension=xdebug.so" -dzend_extension=opcache.so -d 
> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
> -dvld.active=1 -f 
> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
> 48
> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
> array(5) {
>   [5] =>
>   int(1)
>   [6] =>
>   int(-2)
>   [8] =>
>   int(1)
>   [12] =>
>   int(1)
>   [14] =>
>   int(1)
> }
> 
> Where as with PHP 7.3.0, they both show the *unoptimised* version:
> 
> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.3.0/bin/php  -n 
> -dzend_extension=opcache.so  -d "zend_extension=xdebug.so" -d 
> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
> -dvld.active=1 -f 
> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
> 48
> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
> array(5) {
>   [5] =>
>   int(1)
>   [6] =>
>   int(-2)
>   [8] =>
>   int(1)
>   [12] =>
>   int(1)
>   [14] =>
>   int(1)
> }
> [GIT: issue1598-no-code-coverage-with-opcache][PHP: 7.2.13  ]
> derick@singlemalt:~/dev/php/derickr-xdebug $ /usr/local/php/7.3.0/bin/php  -n 
>  -d "zend_extension=xdebug.so" -dzend_extension=opcache.so -d 
> "opcache.enable=1" -d "opcache.enable_cli=1" -d "xdebug.extended_info=1" 
> -dvld.active=1 -f 
> "/home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php"
> 48
> /home/derick/dev/php/derickr-xdebug/tests/bug00213-php73-opcache.php:7:
> array(5) {
>   [5] =>
>   int(1)
>   [6] =>
>   int(-2)
>   [8] =>
>   int(1)
>   [12] =>
>   int(1)
>   [14] =>
>   int(1)
> }
> 
> Curiously, vld, would always show the right (optimised) opcodes:
> 
> filename:   /home/derick/dev/php/derickr-xdebug/tests/bug00213.inc
> function name:  (null)
> number of ops:  12
> compiled vars:  !0 = $e
> line #* E I O op   fetch  ext  return  
> operands
> -
>5 0  E >   EXT_STMT
>  1NEW  $1  :-5
>  2EXT_FCALL_BEGIN
>  3DO_FCALL  0
>  4EXT_FCALL_END
>  5  > THROW 0  $1
>8 6  E > > CATCH
> 'Exception', !0
>   12 7>   EXT_STMT
>  8ECHO 48
>  9EXT_STMT
> 10ECHO 
> '%0A'
>   1411  > RETURN   1
> 
> branch: #  0; line: 5-5; sop: 0; eop: 5; out0:  -2
> branch: #  6; line: 8-8; sop: 6; eop: 6; out0:   7; out1:  -2
> branch: #  7; line:12-   14; sop: 7; e

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

[Levi Morrison]

Dmitry,

I am very interested in FFI behavior. I voted no only because I do not
believe this extension is mature enough for inclusion in core. Getting
TensorFlow to work in PHP-land using the FFI is definitely an
interesting and noteworthy achievement, but I think it is insufficient
for inclusion in core. For such a powerful (and dangerous) feature I
believe it needs more usage for inclusion in core. Again, good work.

Levi Morrison

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

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

[Niklas Keller]

Am Sa., 22. Dez. 2018 um 11:32 Uhr schrieb Nikita Popov :
>
> On Thu, Dec 20, 2018 at 4:13 PM Dmitry Stogov  wrote:
>
> > Hi internals,
> >
> >
> > The FFI RFC is turned into voting state.
> >
> >
> > https://wiki.php.net/rfc/ffi
> >
> >
> > There were very few minor changes since the initial proposal, e.g.
> > renaming FFI:array_type() into FFI::arrayType()
> >
> >
> > Thanks. Dmitry.
> >
>
> My main concern here is that this is a very new extension and I think that
> apart from you barely anyone had a chance to actually implement something
> based on it and gain experience using the proposed API. Bundling an
> extension with PHP means that the API becomes frozen in time and it becomes
> very hard to change anything.

Same here, I think it's better to have it as an extension for now, so
people have time to experiment with it.

In case the vote passes, do we want to mark the feature explicitly as
experimental and not covered by the usual BC guarantee?

Regards, Niklas

> I think that having FFI support is important, but I'm afraid that once we
> bundle this extension and it will see more usage, it will quickly turn out
> that the API needs to change to make it easier to use or accommodate more
> use-cases.
>
> My other concern is platform support. FFI is by nature a rather platform
> dependent. The RFC says that the extension is currently tested on Linux and
> Windows. It would be great if someone using such a system can confirm
> whether it also works on OSX and FreeBSD, so we at least have coverage of
> the major platforms.
>
> Nikita

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