Re: [PHP-DEV] Segfault in master with PHPUnit
Hey Bob: On Sun, Jun 14, 2015 at 2:08 PM, Sebastian Bergmann sebast...@php.net wrote: Am 14.06.2015 um 07:55 schrieb Xinchen Hui: maybe related to this : 3cfa58367b1b85d346d9be6cf9ae116c63571247 Yes, reverting that commit fixes it. Thanks for the pointer! please have a look of it.. I'd like revert it for now.. commit it again when it is fixed... ? thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Segfault in master with PHPUnit
Am 14.06.2015 um 07:55 schrieb Xinchen Hui: maybe related to this : 3cfa58367b1b85d346d9be6cf9ae116c63571247 Yes, reverting that commit fixes it. Thanks for the pointer! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Throwable Interface
Hi Dmitry, I would go by accepting this. Furthermore – if you feel that the implementation is stable enough and does not BC, I would suggest to have it already in the alpha2. As there seems to be at all no resistance in the votes (no even single “no” voter yet), nor strong objection here on the lists. The minimal voting period is 1 week, so theoretically if it were ended on Wed (the voting RFC doesn’t disallow this) – there were still some time to do extensive testing and fixes. Alpha2 is the time where a) a lot of users will be able to test it and b) it still can be reverted in the worst case. What do you think? Regards Anatol From: Dmitry Stogov [mailto:dmi...@zend.com] Sent: Wednesday, June 10, 2015 9:37 AM To: Levi Morrison; Aaron Piotrowski; Nikita Popov Cc: internals; Anatol Belski; Kalle Sommer Nielsen Subject: Re: [PHP-DEV] [RFC] Throwable Interface On Tue, Jun 9, 2015 at 9:13 PM, Levi Morrison le...@php.net mailto:le...@php.net wrote: On Tue, Jun 9, 2015 at 11:40 AM, Aaron Piotrowski aa...@icicle.io mailto:aa...@icicle.io wrote: Does anyone have any questions, comments, or concerns about the Throwable Interface RFC? http://wiki.php.net/rfc/throwable-interface The proposed exception hierarchy: interface Throwable ⊢ Exception implements Throwable ∟ Error implements Throwable (replaces EngineException) ⊢ TypeError (replaces TypeException) ∟ ParseError (replaces ParseException) I’d like to complete a vote before too many alpha releases are made. I’ll be happy to resolve the merge conflicts in the PR if the vote passes. My only objections have already been raised, but I'll reiterate them briefly: 1. Having both Error and Exception makes little sense, especially since we have historically used error to refer to an error that wasn't an exception (something that triggered the error handler). 2. The name Error is going to have a fairly high collision rate with user code. I also like EngineException more than Error. 3. I think they should all use Exception as the root instead having a new root with multiple children (and yes, I am aware of the impact of this, and it has already been discussed on this list). This done on purpose. To prevent catching of new exceptions by old PHP code. If we won't accept this now (before 7.0 release), it would make more troubles in the future. I didn't make deep code review, and don't know all possible consequences. Anyway, I would make a chance to accept this now or never. RM, your thoughts? In case we decide to vote for this RFC, I'll make code review and will help with possible problems. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!
Rasmus Lerdorf in php.internals (Sat, 13 Jun 2015 16:14:37 -0700): On Jun 13, 2015, at 14:54, Jan Ehrhardt php...@ehrhardt.nl wrote: Rasmus Lerdorf in php.internals (Fri, 12 Jun 2015 13:13:16 -0700): You can get even more speed by compiling with --enable-opcache-file and then in your php-cli.ini add: opcache.enable_cli=1 opcache.file_cache=/var/tmp opcache.file_cache_only=1 Then every time you run composer it won't have to recompile everything. I saw something referring to this in the commits. But some documentation would be welcome. I could not find any at the obvious places: http://php.net/manual/en/opcache.configuration.php https://github.com/zendtech/ZendOptimizerPlus Is this documented elsewhere? No, not yet. It is rather new and untested. And not enabled by default. There are still a few minor issues with it, but we need a few more people playing with it so we can work through those which is why I am suggesting folks here give it a try before we document and push it more broadly. OK, I recmpiled my Windows builds with --enable-opcache-file: https://www.apachelounge.com/viewtopic.php?p=30718#30718 Example of a generated phpinfo(): https://phpdev.toolsforresearch.com/php-7.0.0alpha1-nts-Win32-VC14-x64.htm Maybe some Windows guys also want to test it. -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing!
Hi Jan, -Original Message- From: Jan Ehrhardt [mailto:php...@ehrhardt.nl] Sent: Sunday, June 14, 2015 8:11 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] PHP 7.0.0alpha1 Released for Testing! Rasmus Lerdorf in php.internals (Sat, 13 Jun 2015 16:14:37 -0700): On Jun 13, 2015, at 14:54, Jan Ehrhardt php...@ehrhardt.nl wrote: Rasmus Lerdorf in php.internals (Fri, 12 Jun 2015 13:13:16 -0700): You can get even more speed by compiling with --enable-opcache-file and then in your php-cli.ini add: opcache.enable_cli=1 opcache.file_cache=/var/tmp opcache.file_cache_only=1 Then every time you run composer it won't have to recompile everything. I saw something referring to this in the commits. But some documentation would be welcome. I could not find any at the obvious places: http://php.net/manual/en/opcache.configuration.php https://github.com/zendtech/ZendOptimizerPlus Is this documented elsewhere? No, not yet. It is rather new and untested. And not enabled by default. There are still a few minor issues with it, but we need a few more people playing with it so we can work through those which is why I am suggesting folks here give it a try before we document and push it more broadly. OK, I recmpiled my Windows builds with --enable-opcache-file: https://www.apachelounge.com/viewtopic.php?p=30718#30718 Example of a generated phpinfo(): https://phpdev.toolsforresearch.com/php-7.0.0alpha1-nts-Win32-VC14- x64.htm It is by default on in the snapshot build, so is it in alpha1. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array dereferencing of scalars
On 14 June 2015 04:33:16 BST, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Rowan, On Thu, Jun 11, 2015 at 5:59 PM, Rowan Collins rowan.coll...@gmail.com wrote: This one has given a different message because of it being a non-string value, but would be equally fatal if you tried to call any undefined function. Would coercing NULL to an imaginary function which returns NULL actually be useful for anything? For example, getting NULL handler as the default. This is useful like $v=NULL;$v[1][2][3]; I was talking specifically about using NULL as a *function*, not an *array*. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Throwable Interface
On Jun 14, 2015, at 11:31 AM, Anatol Belski anatol@belski.net wrote: Hi Dmitry, I would go by accepting this. Furthermore – if you feel that the implementation is stable enough and does not BC, I would suggest to have it already in the alpha2. As there seems to be at all no resistance in the votes (no even single “no” voter yet), nor strong objection here on the lists. The minimal voting period is 1 week, so theoretically if it were ended on Wed (the voting RFC doesn’t disallow this) – there were still some time to do extensive testing and fixes. Alpha2 is the time where a) a lot of users will be able to test it and b) it still can be reverted in the worst case. What do you think? Regards Anatol I will have some time to resolve the merge conflicts later today, so I will be happy to take care of that. Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Packed array is not fast?
Hi Levi, On Mon, Jun 15, 2015 at 12:35 PM, Levi Morrison le...@php.net wrote: How are you testing hash vs packed? As far as what you posted I cannot tell a difference – it looks like you are running the same thing twice (same binary and same input file). I've modified START index and verified both packed and unpacked array is used by using gdb. I didn't analyze whole execution, but only zend_hash.c I didn't paste slightly different code because it will not give us much difference and it's useless services like 3v4l. I'm a little disappointed by the result because I was expecting much better result with packed array.. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Packed array is not fast?
On Thu, Jun 11, 2015 at 4:21 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I've tried to see how packed array is faster with following code http://3v4l.org/TQd6c I confirmed when start index is non-zero, hash is used by zend_hash_index_find(). I got following result. (with much larger number of elements/loops) Fedora 22 + current master without --enable-debug 1st Time is total execution time. 2nd Time is the time spent by for loop Hash [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.7903809547424 Time: 1.1529920101166 [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.8049499988556 Time: 1.1719739437103 Packed [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.7407248020172 Time: 1.1594388484955 [yohgaki@dev php-src]$ ./php-bin ~/tmp/array_bench2.php Time: 1.7248120307922 Time: 1.1530420780182 Packed array is not so fast, even if zend_hash.c seems much faster with packed array. Just FYI. Regards, P.S. Am I doing something wrong? HHVM seems to have optimization margins for hash and loop. -- Yasuo Ohgaki yohg...@ohgaki.net How are you testing hash vs packed? As far as what you posted I cannot tell a difference – it looks like you are running the same thing twice (same binary and same input file). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
