Re: [PHP-DEV] [RFC][Vote] Return Types

2015-01-27 Thread Dmitry Stogov
d a lot of failing > return types tests. Could you (and anyone else willing) pull it and see if > you are getting failing tests for release and debug builds? > > Cheers, > > Levi Morrison > > > On Tue, Jan 27, 2015 at 1:13 PM, Dmitry Stogov wrote: > >> Hi Lev

Re: [PHP-DEV] Improvements to for-each implementation

2015-01-27 Thread Dmitry Stogov
On Jan 28, 2015 2:36 AM, "Nikita Popov" wrote: > > On Tue, Jan 27, 2015 at 5:55 PM, Dmitry Stogov wrote: >> >> Hi, >> >> I'm working on a PoC, implementing the proposed behavior - https://gist.github.com/dstogov/a311e8b0b2cabee4dab4 >> >

Re: [PHP-DEV] [RFC] [VOTE] Fast Parameter Parsing API

2015-01-27 Thread Dmitry Stogov
The voting is closed. It's passed with 19 voters for and 1 against. Thanks. Dmitry. On Mon, Jan 19, 2015 at 5:25 PM, Pierre Joye wrote: > > On Jan 19, 2015 9:17 PM, "Dmitry Stogov" wrote: > > > > I'd like to initiate a vote on this RFC: > >

Re: [PHP-DEV] [RFC][Vote] Return Types

2015-01-27 Thread Dmitry Stogov
Hi Levi, Do you like me to make final check and merge your pull request? We need it :) Thanks. Dmitry. On Sat, Jan 24, 2015 at 8:01 AM, Levi Morrison wrote: > On Fri, Jan 23, 2015 at 5:06 PM, Levi Morrison wrote: > > As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will > > clo

Re: [PHP-DEV] Improvements to for-each implementation

2015-01-27 Thread Dmitry Stogov
Hi, I'm working on a PoC, implementing the proposed behavior - https://gist.github.com/dstogov/a311e8b0b2cabee4dab4 Only few PHPT tests had to be changed to confirm new behavior and actually they started to behave as HHVM. 2 tests are still unfixed XFAILed. Foreach by reference is still need to b

Re: [PHP-DEV] PHP7 Homework for everyone reading this list

2015-01-23 Thread Dmitry Stogov
Thanks. This problem was introduced yesterday and must be already fixed. Dmitry. On Fri, Jan 23, 2015 at 7:45 AM, Juan Basso wrote: > Trying to run phpunit on the latest CakePHP 3 gives a lot of errors of this > type (not on every test case): > > php: /.../php-src/Zend/zend_gc.c:144: gc_possibl

Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list

2015-01-23 Thread Dmitry Stogov
"master" branch. On Fri, Jan 23, 2015 at 12:43 AM, Jan Ehrhardt wrote: > Rasmus Lerdorf in php.internals (Thu, 22 Jan 2015 09:05:28 -0800): > >Hopefully everyone here knows how to compile from git and get things up > >and running. > > I would love to test a Windows build with all kinds of exten

[PHP-DEV] Re: commit e21fefde381cdd64dc93116440f3ee159c721fa1 breaks tests

2015-01-22 Thread Dmitry Stogov
All these tests pass for me (with and without valgrind). Please, send me the link to Travis report. Thanks. Dmitry. On Thu, Jan 22, 2015 at 10:42 PM, Stanislav Malyshev wrote: > Hi! > > Looks like commit e21fefde381cdd64dc93116440f3ee159c721fa1 leads to 3 > tests broken on CI: > > Bug #54268 (D

Re: [PHP-DEV] PHP7 Homework for everyone reading this list

2015-01-22 Thread Dmitry Stogov
Hi, Our attempt to run Drupal-8 today, disclosed at least 3 new problems. 2 of them must be already fixed, but I know we must have a lot of other problems uncovered by our test suite. Every new tested app my trigger something new. The more attention we draw now the better quality we will provide.

Re: [PHP-DEV] Improvements to Hastable Bucket structure

2015-01-21 Thread Dmitry Stogov
Hi, Xinchen already tried something similar, but it made PHP slower, because it made access to Bucket->key->h more expensive - two loads with most probably two CPU cache misses instead of one. Thanks. Dmitry. On Thu, Jan 22, 2015 at 9:43 AM, Benjamin Coutu wrote: > Hi, > > Currently a hashtabl

Re: [PHP-DEV] Fixing strange foreach behavior.

2015-01-21 Thread Dmitry Stogov
Hi, Yeah, I think changing foreach behaviour in more consistent and efficient way may make sense. If we won't use HashTable.nInternalPointer we won't need to copy immutable arrays. The same for nested foreach on the same array. We could also eliminate all the HashPosition magic introduced to keep

Re: [PHP-DEV] [RFC][DISCUSSION] Removal of dead SAPIs and extensions

2015-01-19 Thread Dmitry Stogov
Hi Anatol, Despite of this, we also have few extensions not converted to PHP7 yet - https://wiki.php.net/phpng#unsupported_extensions_not_converted_yet 3 of them related to MSSQL, 2 to Oracle and one to Interbase. the last one is partially converted (may be compiled), but it's so ugly, so it won'

[PHP-DEV] [RFC] [VOTE] Fast Parameter Parsing API

2015-01-19 Thread Dmitry Stogov
I'd like to initiate a vote on this RFC: https://wiki.php.net/rfc/fast_zpp It proposes an additional fast way to parse arguments of internal functions. The implementation was included into phpng before merging into php-7, but we were agree

[PHP-DEV] Re: [PHP-CVS] com php-src: Add IntlChar class to intl extension: ext/intl/config.m4 ext/intl/config.w32 ext/intl/php_intl.c ext/intl/uchar/tests/basic-functionality.phpt ext/intl/uchar/ubloc

2015-01-19 Thread Dmitry Stogov
Hi Sara, This patch increased the size of resulting PHP code size by 80KB. I know, it's less than 1%, but unfortunately it also affects performance on absolutely unrelated code. This patch leads to increase in iTLB-loads from 17K to 21K on each request to Wordpress home page and as result in sligh

[PHP-DEV] Re: [PHP-CVS] Broken apps

2015-01-19 Thread Dmitry Stogov
hi Pierre, please send your test results when they available. Thanks. Dmitry. On Mon, Jan 19, 2015 at 1:11 PM, Pierre Joye wrote: > > On Jan 19, 2015 4:49 PM, "Dmitry Stogov" wrote: > > > > Despite of PEAR, I also found few other apps, from my usual test lis

[PHP-DEV] Re: Broken apps

2015-01-19 Thread Dmitry Stogov
, Jan 19, 2015 at 12:49 PM, Dmitry Stogov wrote: > Despite of PEAR, I also found few other apps, from my usual test list, > broken - Typo3, Xoops, SugarCRM. > Magento is broken long time ago by "unified variable syntax". > > I'm really unhappy with this direction...

[PHP-DEV] Broken apps

2015-01-19 Thread Dmitry Stogov
Despite of PEAR, I also found few other apps, from my usual test list, broken - Typo3, Xoops, SugarCRM. Magento is broken long time ago by "unified variable syntax". I'm really unhappy with this direction... Thanks. Dmitry. On Mon, Jan 19, 2015 at 12:18 PM, Dmitry Stogov wr

Re: [PHP-DEV] Generating more efficient code for while-loop

2015-01-16 Thread Dmitry Stogov
I'm going to commit it on Monday. Xinchen, Nikita, please verify me. Thanks. Dmitry. On Fri, Jan 16, 2015 at 7:58 PM, Xinchen Hui wrote: > Hey: > > On Sat, Jan 17, 2015 at 12:12 AM, Dmitry Stogov wrote: > > Hi Benjamin, > > > > Thanks for idea. > > With PHP7

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

2015-01-16 Thread Dmitry Stogov
I was just surprised by the current behavior :) $ cat ops.php $ sapi/cli/php -n ops.php Catchable fatal error: Argument 1 passed to foo() must be an instance of string, string given in ops.php on line 2 It too me time to realize what is going on :) Thanks. Dmitry. On Fri, Jan 16, 2015 at 6:

Re: [PHP-DEV] Generating more efficient code for while-loop

2015-01-16 Thread Dmitry Stogov
Hi Benjamin, Thanks for idea. With PHP7 AST compiler, it's quite easy to implement this (it took us 15 minutes to try :) However, it doesn't make big improvement on our benchmarks. We will take a look into possibilities to apply your idea to other patterns (e.g. for and foreach loops). Anyway, it

Re: [PHP-DEV] [RFC] Big Integer Support

2015-01-15 Thread Dmitry Stogov
, Andrea Faulds wrote: > Hey Dmitry, > > On 15 Jan 2015, at 07:56, Dmitry Stogov wrote: > > ext/session and ext/json are required by most apps. > Actually I stopped attempts to build it when I saw compilation errors in > ext/session. > > Thanks. Dmitry. > > >

Re: [PHP-DEV] [RFC] Big Integer Support

2015-01-15 Thread Dmitry Stogov
I don't know which ones are supported or not. Of course we need some extension to connect to database mysql, mysqli or pdo_mysql. Thanks. Dmitry. On Thu, Jan 15, 2015 at 11:03 AM, Pierre Joye wrote: > On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov wrote: > > ext/session an

Re: [PHP-DEV] [RFC] Big Integer Support

2015-01-14 Thread Dmitry Stogov
ext/session and ext/json are required by most apps. Actually I stopped attempts to build it when I saw compilation errors in ext/session. Thanks. Dmitry. On Thu, Jan 15, 2015 at 10:44 AM, Pierre Joye wrote: > On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov wrote: > > Oh, it's

Re: [PHP-DEV] [RFC] Big Integer Support

2015-01-14 Thread Dmitry Stogov
Jan 2015, at 19:43, Dmitry Stogov wrote: > > > > Hi Andrea, > > > > Where can I get the code? > > > > Thanks. Dmitry. > > Hey Dmitry, > > The bigint-libtommath branch was merged back into the bigint branch since > I figured there was no point keepin

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

2015-01-14 Thread Dmitry Stogov
In my opinion, version 0.1 was consistent enough. handling two different approaches just makes mess... We have internal function strlen(string $s), and it may be called with integer argument e.g. strlen(123) -> 3 I think user functions should follow the same rules. If some rules are "bad", lets

Re: [PHP-DEV] Faster zend sorting implementation

2015-01-14 Thread Dmitry Stogov
IR - Instruction Retired. We measure them using callgrind to analyze micro-improvements. See https://wiki.php.net/phpng#performance_evaluation for more details. Thanks. Dmitry. On Wed, Jan 14, 2015 at 5:56 PM, Alexander Kurilo wrote: > Hi Xinchen, > >> my draft patch (which already get 0

Re: [PHP-DEV] [RFC] Big Integer Support

2015-01-14 Thread Dmitry Stogov
Hi Andrea, Where can I get the code? Thanks. Dmitry. On Thu, Jan 8, 2015 at 7:02 PM, Dmitry Stogov wrote: > I'm really surprised by the results :) > I'll try to find time for bigint on next week and play with it a bit. > > Thanks. Dmitry. > > > On Wed, Jan 7,

[PHP-DEV] Re: Faster zend sorting implementation

2015-01-14 Thread Dmitry Stogov
I don't see big problems committing this. In some cases new sort() functions may provide different results, but they are still valid, because the order of "equal" elements after sort is not defined. Thanks. Dmitry. On Wed, Jan 14, 2015 at 12:59 PM, Xinchen Hui wrote: > Hey: > > I made a PR

Re: [PHP-DEV] Re: [Pre-Vote] Return Types

2015-01-09 Thread Dmitry Stogov
yeah, I remember I saw something :) Lets do the core work first and then decide how the Reflection should look like. Thanks. Dmitry. On Fri, Jan 9, 2015 at 9:26 PM, Levi Morrison wrote: > > The implementation misses support for reflection. > > I think, it doesn't make a lot of sense to introduc

Re: [PHP-DEV] Re: [Pre-Vote] Return Types

2015-01-08 Thread Dmitry Stogov
Hi, I've updated the implementation and now it's even more consistent (it shares code for return and argument type hinting). https://github.com/php/php-src/pull/986/files The implementation misses support for reflection. I think, it doesn't make a lot of sense to introduce Reflection support for

Re: [PHP-DEV] [RFC] Big Integer Support

2015-01-08 Thread Dmitry Stogov
I'm really surprised by the results :) I'll try to find time for bigint on next week and play with it a bit. Thanks. Dmitry. On Wed, Jan 7, 2015 at 2:54 AM, Andrea Faulds wrote: > Hey Dmitry, > > > On 23 Oct 2014, at 16:22, Dmitry Stogov wrote: > > > >>

[PHP-DEV] Re: Faster zend sorting implementation

2015-01-06 Thread Dmitry Stogov
I think this break is acceptable Of course, if the new sort implementation significantly improves performance on some cases and doesn't show degradation on the others. Thanks. Dmitry. On Jan 5, 2015 9:08 PM, "Xinchen Hui" wrote: > Hey: > > I was working on zend_qsort improvement. but I got

[PHP-DEV] Re: Merge HashTable and zend_array into a single data structure.

2015-01-01 Thread Dmitry Stogov
Hi Nikita, On Jan 1, 2015 5:23 PM, "Nikita Popov" wrote: > > On Wed, Dec 31, 2014 at 11:19 AM, Dmitry Stogov wrote: >> >> Hi, >> >> Please take a look into the patch >> >> https://github.com/php/php-src/pull/970/files >> >> This rea

RE: [PHP-DEV] Merge HashTable and zend_array into a single data structure.

2015-01-01 Thread Dmitry Stogov
Hi François, this is not a proposal yet, this is just an initial request to the most experinced PHP developers to think about possible consequnces. Thanks. Dmitry. On Dec 31, 2014 9:50 PM, "François Laupretre" wrote: > > De : Dmitry Stogov [mailto:dmi...@zend.com] > > >

Re: [PHP-DEV] Merge HashTable and zend_array into a single data structure.

2015-01-01 Thread Dmitry Stogov
except for slight increase of memory consumption. Thanks. Dmitry. On Jan 1, 2015 12:26 AM, "Anatol Belski" wrote: > Hi Dmitry, > > On Wed, December 31, 2014 11:19, Dmitry Stogov wrote: > > Hi, > > > > > > Please take a look into the patch > > > >

[PHP-DEV] Merge HashTable and zend_array into a single data structure.

2014-12-31 Thread Dmitry Stogov
Hi, Please take a look into the patch https://github.com/php/php-src/pull/970/files This real changes are in zend_types.h, the rest is renaming that in most cases makes code cleaner. zend_array didn't change its binary representation, but now it's not possible to get a pointer to embedded HashT

[PHP-DEV] Re: [php-src] Allow arrays with define(), to match const syntax support (#951)

2014-12-20 Thread Dmitry Stogov
Hi Andrea, Sorry, I thought you were gong to provide a patch for master. I think it's better not to apply this in 5.6. Even if it won't make technical problems it'll bring incompatibility between minor 5.6.* versions. I made a patch for master on top of yours - https://gist.github.com/dstogov/395

Re: [PHP-DEV] 64-bit performance improvement by reducing zend_op size.

2014-12-11 Thread Dmitry Stogov
). It always makes improvement. :) Thanks. Dmitry, On Thu, Dec 11, 2014 at 1:05 PM, Patrick ALLAERT wrote: > Hi, > > 2014-12-10 16:27 GMT+01:00 Dmitry Stogov : > > Hi, > > > > Please, review the following patch > > https://gist.github.com/dstogov/fba2cc621ef12

Re: [PHP-DEV] [VOTE][RFC] Native TLS

2014-12-10 Thread Dmitry Stogov
+1 the patch is great. It doesn't affect non-ZTS build at all. ZTS build became even a bit faster. :) And we finally will able to forget about TSRMLS_ macros :) Non-ZTS ZTS master native-tls master native-tls bench.php [sec] 1.193 1.195 1.313 1.299 micro_bench.php [sec] 6.008 6.064 7.470 6.786

[PHP-DEV] 64-bit performance improvement by reducing zend_op size.

2014-12-10 Thread Dmitry Stogov
Hi, Please, review the following patch https://gist.github.com/dstogov/fba2cc621ef121826efe It's huge, but actually, only changes in zend_compile.h are matter. The rest is obvious renaming. the main idea - the smaller the zend_op structure, the lees memory traffic is required to load VM instruct

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Dmitry Stogov
I'm not against the patch, I'm actually indifferent. Lets wait for Nikita's opinion. I took just a quick look over "static class" RFC. I'll need to think more about it. Thanks. Dmitry. On Mon, Dec 8, 2014 at 5:18 PM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Hi Dmitry, > >

Re: [PHP-DEV] Zend language parser improvements

2014-12-08 Thread Dmitry Stogov
I don't see technical problems with the patch. However, I also don't see any significant benefits. >From the user perspective it'll just change error messages and prevent "final final class" declarations. Nikita, what do you think? Thanks. Dmitry. On Fri, Dec 5, 2014 at 8:18 PM, guilhermebla...@

Re: [PHP-DEV] Use zend_string* for op_array->arg_info[].name and class_name

2014-12-02 Thread Dmitry Stogov
I'm going to commit this, if nobody objects. Thanks. Dmitry. On Mon, Dec 1, 2014 at 2:08 PM, Dmitry Stogov wrote: > See the updated patch: > https://gist.github.com/dstogov/08b545de6bf113113f58 > it can be safely applied again and simplifies inheritance code (thanks to > Lev

Re: [PHP-DEV] Use zend_string* for op_array->arg_info[].name and class_name

2014-12-01 Thread Dmitry Stogov
now the inheritance code is clear enough. Thanks. Dmitry. On Mon, Dec 1, 2014 at 11:02 AM, Dmitry Stogov wrote: > Hi Levi, > > I understood, that you don't see a big problems with the patch. :) > > According to your suggestions, It's possible to do it in this way, but

Re: [PHP-DEV] Re: EX(scope) removing

2014-12-01 Thread Dmitry Stogov
t/opcahce" tests are excluded as well. Thanks. Dmitry. On Sun, Nov 30, 2014 at 7:25 PM, Ferenc Kovacs wrote: > > 2014.11.30. 11:14 ezt írta ("Dmitry Stogov" ): > > > > Sorry, I'll try to fix it on Monday. > > is it a compilation problem, or how can re

Re: [PHP-DEV] Use zend_string* for op_array->arg_info[].name and class_name

2014-12-01 Thread Dmitry Stogov
Hi Levi, I understood, that you don't see a big problems with the patch. :) According to your suggestions, It's possible to do it in this way, but it's going to be slower, because it would require additional memory allocation, but I agree that duplicating logic in the code isn't good. It must be

Re: [PHP-DEV] Re: EX(scope) removing

2014-11-30 Thread Dmitry Stogov
Sorry, I'll try to fix it on Monday. is it a compilation problem, or how can reproduce it? Thanks. Dmitry. On Sat, Nov 29, 2014 at 1:01 AM, Ferenc Kovacs wrote: > 2014.11.28. 9:24 ezt írta ("Dmitry Stogov" ): > > > > > On Fri, Nov 28, 2014 at 7:33 AM,

Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking

2014-11-28 Thread Dmitry Stogov
Hi Levi, if you remember, in my patch return_type was actually stored in arg_info[-1]. it was mainly done for unification and to allow return type hinting for internal functions (they already use arg_info[-1]) So the strictures may be compatible. See https://gist.github.com/dstogov/8deb8b17e41c1a5

Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking

2014-11-28 Thread Dmitry Stogov
I didn't get what you mean. parameters are invariant, "invariance, which is safe for both" and " it shouldn't match parameters" are contradictory. Thanks. Dmitry. On Fri, Nov 28, 2014 at 1:57 PM, Andrea Faulds wrote: > > > On 28 Nov 2014, at 09:31, Dmitry

Re: [PHP-DEV] [RFC][Discussion] Return Type Variance Checking

2014-11-28 Thread Dmitry Stogov
I prefer option (3) - invariant return types. Actually, return type compatibility check should follow all the rules for parameter type compatibility check (may be even reuse or share the code). This solution may be implemented efficiently and consistently. It also must be enough for 99% use cases.

Re: [PHP-DEV] PowerPC64 patchs

2014-11-28 Thread Dmitry Stogov
I see no problems with these patches. If all tests on PPC are passed, then they should be accepted. The patches won't affect other architectures. Anybody tested? Thanks. Dmitry. On Thu, Nov 27, 2014 at 3:39 PM, Gustavo Frederico Temple Pedrosa < gustavo.pedr...@eldorado.org.br> wrote: > Hi, int

[PHP-DEV] Re: EX(scope) removing

2014-11-28 Thread Dmitry Stogov
On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui wrote: > Hey: > > On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov wrote: > > Hi, > > > > I'm working on call/return sequence optimization. As part of this work > I'm > > minimizing the size of call fr

Re: [PHP-DEV] EX(scope) removing

2014-11-27 Thread Dmitry Stogov
Yes, we may store EX(called_scope) in EX(This).value.ce and set another type and/or flag(s). But it shouldn't slowdown $this access in _get_obj_zval_ptr_unused() and other often used functions. If it's possible, we may try to merge, if not, it doesn't make sense. Thanks. Dmitry. On Thu, Nov 27, 2

Re: [PHP-DEV] EX(scope) removing

2014-11-27 Thread Dmitry Stogov
Thanks. Probably, I'll commit it tomorrow. Dmitry. On Thu, Nov 27, 2014 at 9:09 PM, Matteo Beccati wrote: > Hi Dmitry, > > On 27/11/2014 18:27, Dmitry Stogov wrote: > >> Could you please take a look into the patch that removes EX(scope) >> https://gist.github.com

[PHP-DEV] EX(scope) removing

2014-11-27 Thread Dmitry Stogov
Hi, I'm working on call/return sequence optimization. As part of this work I'm minimizing the size of call frame (zend_execute_data) and number of read/write operations on call/return. Could you please take a look into the patch that removes EX(scope) https://gist.github.com/dstogov/5ad50d5823463

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

2014-11-25 Thread Dmitry Stogov
On Tue, Nov 25, 2014 at 2:18 PM, Andrea Faulds wrote: > > > On 25 Nov 2014, at 10:41, Dmitry Stogov wrote: > > > > u8"string" tells that the whole string is UTF-8 encoded. > > Your escape Unicode proposal assumes just UTF-8 codepoint, but the >

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

2014-11-25 Thread Dmitry Stogov
On Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds wrote: > > > On 25 Nov 2014, at 08:33, Dmitry Stogov wrote: > > > > May be I misunderstood something, but why to introduce unicode escapes > if PHP engine doesn't support Unicode. > > We don't have Unic

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

2014-11-25 Thread Dmitry Stogov
May be I misunderstood something, but why to introduce unicode escapes if PHP engine doesn't support Unicode. Always converting such escapes into UTF-8 encoding, doesn't make any sense for people who use other encodings for output, databases, etc. Thanks. Dmitry. On Tue, Nov 25, 2014 at 1:09

[PHP-DEV] Re: Use zend_string* for op_array->arg_info[].name and class_name

2014-11-24 Thread Dmitry Stogov
on, Nov 24, 2014 at 5:27 PM, Nikita Popov wrote: > On Mon, Nov 17, 2014 at 10:25 AM, Dmitry Stogov wrote: > >> Hi, >> >> Please review the patch >> https://gist.github.com/dstogov/47a39aff37f0a6441ea0 >> >> Thanks. Dmitry. >> > > Hi Dmitry,

Re: [PHP-DEV] [RFC] Default constructors

2014-11-24 Thread Dmitry Stogov
code should work or should not). Thanks. Dmitry. On Fri, Nov 21, 2014 at 10:40 AM, Dmitry Stogov wrote: > thanks Stas. I'll think on next week. > > Dmitry. > > On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev > wrote: > >> Hi! >> >> >> Add

Re: [PHP-DEV] [RFC] Default constructors

2014-11-20 Thread Dmitry Stogov
thanks Stas. I'll think on next week. Dmitry. On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev wrote: > Hi! > > >> Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive. > >> I think it must be better to use special predefined function (see > >> "zend_pass_function" usage in z

Re: [PHP-DEV] [RFC] Default constructors

2014-11-20 Thread Dmitry Stogov
Hi Stas, Sorry, I didn't follow all the discussions. I think the idea is good. I'm not sure about implementation. Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive. I think it must be better to use special predefined function (see "zend_pass_function" usage in zend_vm_def.h). T

Re: [PHP-DEV] Re: Use zend_string* for op_array->arg_info[].name and class_name

2014-11-18 Thread Dmitry Stogov
Of course, it would be great to always use zend_string, but only arg_info duplication (without char -> zend_string) would add ~90KB on 32-bit system and ~150KB on 64-bit system per process. So I expect 300-500KB wasted per process. Actually, only inheritance and reflection code was complicated by

[PHP-DEV] Re: Use zend_string* for op_array->arg_info[].name and class_name

2014-11-17 Thread Dmitry Stogov
On Tue, Nov 18, 2014 at 7:49 AM, Xinchen Hui wrote: > > > Sent from my iPhone > > On Nov 18, 2014, at 12:34 PM, Dmitry Stogov wrote: > > > > On Tue, Nov 18, 2014 at 6:01 AM, Xinchen Hui wrote: > >> Hey: >> >> >> >> On

[PHP-DEV] Re: Use zend_string* for op_array->arg_info[].name and class_name

2014-11-17 Thread Dmitry Stogov
On Tue, Nov 18, 2014 at 6:01 AM, Xinchen Hui wrote: > Hey: > > > > On Mon, Nov 17, 2014 at 5:25 PM, Dmitry Stogov wrote: > > Hi, > > > > Please review the patch > https://gist.github.com/dstogov/47a39aff37f0a6441ea0 > > I am not sure, why can

[PHP-DEV] Use zend_string* for op_array->arg_info[].name and class_name

2014-11-17 Thread Dmitry Stogov
Hi, Please review the patch https://gist.github.com/dstogov/47a39aff37f0a6441ea0 Thanks. Dmitry.

Re: [PHP-DEV] Re: [RFC][Vote Cancellation] Return Types

2014-11-11 Thread Dmitry Stogov
On Fri, Nov 7, 2014 at 7:20 PM, Levi Morrison wrote: > > A bug was discovered in the implementation of the return types RFC[1] > > that cannot be fixed by the current implementation. A strategy for > > fixing the bug has been identified but alters some noticeable behavior > > in PHP-land. I do no

Re: [PHP-DEV] [RFC][Vote] Return Types

2014-11-06 Thread Dmitry Stogov
ndrea Faulds wrote: > > > On 6 Nov 2014, at 15:08, Dmitry Stogov wrote: > > > > Use A or B for return type in B::foo(). It'll lead to compile error > anyway (Class C is not defined). > > It's not possible to compile this by design. > > Ok, l

Re: [PHP-DEV] [RFC][Vote] Return Types

2014-11-06 Thread Dmitry Stogov
Use A or B for return type in B::foo(). It'll lead to compile error anyway (Class C is not defined). It's not possible to compile this by design. Thanks. Dmitry. On Thu, Nov 6, 2014 at 6:00 PM, Andrea Faulds wrote: > > > On 6 Nov 2014, at 07:43, Dmitry Stogov wrote:

Re: [PHP-DEV] [RFC][Vote] Return Types

2014-11-05 Thread Dmitry Stogov
It's clear, that covariant types are more smart, but not supporting them, won't prevent access to more specific type properties and methods. We are not C++ or Java, and we don't need to cast objects to more specific types. On the other hand covariance requires all return types to be defined before

Re: [PHP-DEV] [RFC][Vote] Return Types

2014-11-05 Thread Dmitry Stogov
I would also prefer to use the same return type hinting compatibility rules as for argument type-hinting. May be it's less smart, but more practical. http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 Thanks. Dmitry. On Thu, Nov 6, 2014 at 1:15 AM, Stas Malyshev w

Re: [PHP-DEV] [RFC][Vote] Return Types

2014-11-05 Thread Dmitry Stogov
On Thu, Nov 6, 2014 at 12:05 AM, Stas Malyshev wrote: > Hi! > > > > Do we always load the class in the hint? We could perhaps only do it > > for inheritance checks? > > No, classes are not loaded for type checks, since it would be pointless > - if the class is not loaded, you could not have a val

Re: [PHP-DEV] [RFC][Vote] Return Types

2014-11-05 Thread Dmitry Stogov
Hi Levi, The patch is here https://gist.github.com/dstogov/8deb8b17e41c1a5abf88 I improved memory consumption and unified return type-hinting error behavior with existing argument type-hinting. The main semantic must be unchanged. I also removed part of Reflection changes. I think we should remov

[PHP-DEV] Re: opcache.revalidate_freq is PHP_INI_ALL?

2014-11-04 Thread Dmitry Stogov
Hi Rasmus, Sorry for delay, I'm just back to work after ZendCon and holidays. opcache.revalidate_freq is PHP_INI_ALL on purpose. Scripts that generate and include the same file again and again should set it to 0 to check for modification on each include. I didn't get what did you meant by "but i

Re: [PHP-DEV] [RFC] Additional splat operator usage

2014-11-04 Thread Dmitry Stogov
I like the idea, especially list($a, $b, ...$c) = ... Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the same semantic and performance. Implementation needs to be reviewed, but I think it must not affect existing opcodes. Thanks. Dmitry. On Tue, Nov 4, 2014 at 1:45 AM, Chris

Re: [PHP-DEV] [RFC] [VOTE] Filtered unserialize()

2014-11-04 Thread Dmitry Stogov
I agree with Nikita. Adding an extra argument for one particular security related case looks weird. Will we add more arguments for others? I would also prefer options array and [] instead of 'false'. unserialize($string, array('allowed_classes'=>[])); It's also more readable :) Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Readonly Properties

2014-10-27 Thread Dmitry Stogov
if there are no conceptual and implantation problems with static readonly properties, it's better to implement them in the same patch. On Mon, Oct 27, 2014 at 11:15 PM, Andrea Faulds wrote: > > > On 27 Oct 2014, at 19:47, Dmitry Stogov wrote: > > > > Oh. I meant st

Re: [PHP-DEV] [RFC] Readonly Properties

2014-10-27 Thread Dmitry Stogov
On Mon, Oct 27, 2014 at 10:25 PM, Andrea Faulds wrote: > > > On 27 Oct 2014, at 18:31, Dmitry Stogov wrote: > > > > Hi Andrea, > > > > I don't have strong opinion about this proposal. > > It doesn't make any harm to the engine, and it really may

Re: [PHP-DEV] [RFC] Readonly Properties

2014-10-27 Thread Dmitry Stogov
Hi Andrea, I don't have strong opinion about this proposal. It doesn't make any harm to the engine, and it really may speed-up code especially written for read-only properties. On the other hand you introduce new orthogonal to private/protected/public visibility rule, and I'm not sure if this comp

Re: [PHP-DEV] [RFC] Serialize filtering

2014-10-27 Thread Dmitry Stogov
Hi Stas, I'm not sure if this new argument to unserialize() is intuitive. May be better to use separate functions - unserialize_filtered() or something similar. Thanks. Dmitry. On Mon, Oct 27, 2014 at 11:03 AM, Stas Malyshev wrote: > Hi! > > I'd like to have a vote on unserialize() improvement

Re: [PHP-DEV] [RFC] Big Integer Support

2014-10-23 Thread Dmitry Stogov
On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds wrote: > Hi! > > > On 23 Oct 2014, at 13:47, Dmitry Stogov wrote: > > > > Hi Andrea, > > > > The synthetic benchmarks are not always reflect the impact on real-life > performance. > > > > Unfortu

Re: [PHP-DEV] [RFC] Big Integer Support

2014-10-23 Thread Dmitry Stogov
Hi Andrea, The synthetic benchmarks are not always reflect the impact on real-life performance. Unfortunately, I wasn't able to run any big real-life apps with your bigint branch, because it misses support for commonly used extensions (ext/session, ext/json, ext/pdo). I ran bench.php and it's a

Re: [PHP-DEV] [RFC] UString

2014-10-23 Thread Dmitry Stogov
this won't completely solve the problem, because array keys won't be UString anymore. Thanks. Dmtiry. On Thu, Oct 23, 2014 at 12:11 PM, Joe Watkins wrote: > On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote: > > Hi! > > > > > I wish there was a way for specific objects to opt into this. >

Re: [PHP-DEV] [RFC] Safe Casting Functions

2014-10-22 Thread Dmitry Stogov
exceptions, you always can wrap a userland function > around it — but I’d rather not wrap an userland function around something > throwing an exception… inefficient and weird. > > Thanks, > Bob > > > Am 22.10.2014 um 12:27 schrieb Dmitry Stogov : > > > > "null&

Re: [PHP-DEV] [RFC] Safe Casting Functions

2014-10-22 Thread Dmitry Stogov
"null" or "false" return value would make these functions not really useful, because they won't guarantee to return desired type. printf("%d\n", to_int("abcd")); // will print 0 The only reliable option to support wrong input is exceptions. On the other hand, exceptions maybe difficult to use or

Re: [PHP-DEV] [RFC] Safe Casting Functions

2014-10-22 Thread Dmitry Stogov
On Wed, Oct 22, 2014 at 2:51 AM, Andrea Faulds wrote: > > > On 21 Oct 2014, at 10:14, Dmitry Stogov wrote: > > > > some notes: > > - it's probably make sense to implement these function as a new > opcode(s) in VM > > That could be an optimisation later,

Re: [PHP-DEV] [RFC] UString

2014-10-21 Thread Dmitry Stogov
On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins wrote: > On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote: > > Hi Joe, > > > > > > As an extension it looks fine. > > > > I assume, you don't propose to use UString objects in engine and other >

Re: [PHP-DEV] [RFC] Safe Casting Functions

2014-10-21 Thread Dmitry Stogov
Both, the idea and implementation look fine. Personally, I hate the existing type conversion rules, and I would like to use something like this by default (may be with exception for null/false/true handling), but it may be a big compatibility break, so introducing to_int() is better than nothing.

Re: [PHP-DEV] [RFC] UString

2014-10-21 Thread Dmitry Stogov
Hi Joe, As an extension it looks fine. I assume, you don't propose to use UString objects in engine and other extensions. Unfortunately, it's yet another incomplete solution. It won't allow Unicode strings as array keys; concatenation using "." (probably may be done), no auto-conversion from/to s

Re: [PHP-DEV] [RFC] Big Integer Support

2014-10-21 Thread Dmitry Stogov
Hi Andrea, Why don't you use the ability of operator overloading? (it's in the engine since 5.6). BIGINT don't have to be completely transparent. If user would like to work with BIGINT, let them crate PHP objects explicitly and then use operator overloading. e.g. Your solution would allows wri

[PHP-DEV] Fwd: [PHP-CVS] com php-src: Don't make difference between undefined and unaccessible properies when call __get() and family: Zend/zend_object_handlers.c

2014-10-17 Thread Dmitry Stogov
Please think if it may break something. I wasn't able to find out a case. Thanks. Dmitry. -- Forwarded message -- From: Dmitry Stogov Date: Fri, Oct 17, 2014 at 3:01 PM Subject: [PHP-CVS] com php-src: Don't make difference between undefined and unaccessible properies

Re: [PHP-DEV] RFC: Return Types Update

2014-10-16 Thread Dmitry Stogov
I think the patch already does it (may be not for all magic methods). Thanks. Dmitry. On Thu, Oct 16, 2014 at 2:58 PM, Andrea Faulds wrote: > > On 16 Oct 2014, at 05:39, Levi Morrison wrote: > > > - There is a new section about disallowing return types on certain > methods[4]. > > Perhaps, al

Re: [PHP-DEV] RFC: Return Types Update

2014-10-16 Thread Dmitry Stogov
Hi Chris, I meant scalar type hinting, nullable type hinting, may be even mixed type hinting... But, lets go by small steps to get all this finally accepted. Thanks. Dmitry. On Thu, Oct 16, 2014 at 1:35 PM, Chris Wright wrote: > Dmitry > > On 16 October 2014 08:44, Dmitry Stog

Re: [PHP-DEV] RFC: Return Types Update

2014-10-16 Thread Dmitry Stogov
The RFC is very consistent. It proposes only a part of the desired type-hinting features, but this part is not questionable for me. +1 The implementation has some minor issues. Levi, if you won't object, I would like to play with implementation a bit, right before commit (if it accepted). Thanks

Re: [PHP-DEV] RFC: PHP 7.0 timeline

2014-10-15 Thread Dmitry Stogov
If we aren't able to fix a low-level problem in a year we most probably won't be able to fix it in two as well. Also, the closer we are to release, the more feedback we get, and the more bugs are able to fix. Delaying release would just reduce the attention of the users. Thanks. Dmitry. On Tue,

Re: [PHP-DEV] RFC: PHP 7.0 timeline

2014-10-14 Thread Dmitry Stogov
I think 1 year is reasonable timeline. We still have 5 month for active development and implementation of new ideas. I think https://wiki.php.net/ideas/php6/engine is a bit outdated. I'm not sure if anyone are going to work on proposals from 2009 (even if they are great). It would be great to def

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c

2014-10-13 Thread Dmitry Stogov
bench.php should be faster as well. It must be slower because of not lucky code locality or something like that. Thanks. Dmitry. On Mon, Oct 13, 2014 at 4:40 PM, wrote: > Hi Dmitry, > > thanks for taking a look, > > On Mon, October 13, 2014 13:38, Dmitry Stogov wrote

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c

2014-10-13 Thread Dmitry Stogov
prefer to keep the semantic patch small and don't delete all FETCH_TSRM() in thousand places (at this point). Replacing macro in one place must be easier. It's not a problem to remove them on second step if the PoC would really work. Thanks. Dmitry. On Wed, Oct 8, 2014 at 12:18 PM, Dmi

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

2014-10-13 Thread Dmitry Stogov
Note, that once we move extension outside of main source tree, only extension maintainers (if any) will support them. According to the voting process, I think it makes sense to vote for each feature separately. Thanks. Dmitry. On Sun, Oct 12, 2014 at 4:13 AM, Rasmus Lerdorf wrote: > > On Oc

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Remove support for classes without class entries: Zend/zend_API.c Zend/zend_builtin_functions.c Zend/zend_closures.c Zend/zend_execute.h Zend/zend_interfaces.c

2014-10-10 Thread Dmitry Stogov
gt; >> Hi >> >> On 10 Oct 2014, at 03:57, Dmitry Stogov wrote: >> >> > Yeah, JavaBridge used it, but it doesn't means it need it. >> > >> > zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC) >> > { >> >ret

<    4   5   6   7   8   9   10   11   12   13   >