Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
Hi Nikita, Few final notes: - I wouldn't change zend_object_compare_t into zend_object_compare_objects_t. It would be better to name the new function as zend_object_compare_zvals_t. (It's just for better backward compatibility) - Increment and decrement operators in PHP may have different semantic than +=1, but I it's probably OK to use ADD/SUB for them. - In some cases you insert call to zend_object_do_operation into the most probable path (e.g. in mod_function). This would cause at lease 2 additional comparisons and may be conditional jumps. I think it would be better to check for most probable operand types first... I didn't look into GMP part. Thanks. Dmitry. On Mon, May 13, 2013 at 8:16 PM, Nikita Popov wrote: > On Mon, May 13, 2013 at 1:09 PM, Dmitry Stogov wrote: > >> Hi Nikita, >> >> I didn't get why do we need separate zend_std_compare() function. >> May be I just didn't look careful :) >> > Good point, that was not really necessary. I moved the code back into > compare_function. > > >> It would be great to look into the patch between master and current of >> your branch. >> > You can find a diff between master and my branch on the PR: > https://github.com/php/php-src/pull/342/files > The relevant diff for the compare handler is here: > https://github.com/php/php-src/pull/342/files#L2R1581 > > Nikita >
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Mon, May 13, 2013 at 1:09 PM, Dmitry Stogov wrote: > Hi Nikita, > > I didn't get why do we need separate zend_std_compare() function. > May be I just didn't look careful :) > Good point, that was not really necessary. I moved the code back into compare_function. > It would be great to look into the patch between master and current of > your branch. > You can find a diff between master and my branch on the PR: https://github.com/php/php-src/pull/342/files The relevant diff for the compare handler is here: https://github.com/php/php-src/pull/342/files#L2R1581 Nikita
Re: [PHP-DEV] Heads up - PECL ZendOptimizerPlus repository moved to github.com/zendtech/ZendOptimizerPlus
On Mon, May 13, 2013 at 2:28 PM, Zeev Suraski wrote: > For those of you with direct clones of ZendOptimizerPlus, you’d have to > run: > > git remote set-url origin g...@github.com:zendtech/ZendOptimizerPlus.git > > on your clones for them to continue working. This is not related to the > code that’s already inside the PHP tree. > > > > Zeev > I've updated the links on http://pecl.php.net/package/ZendOpcacheaccordingly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Heads up - PECL ZendOptimizerPlus repository moved to github.com/zendtech/ZendOptimizerPlus
For those of you with direct clones of ZendOptimizerPlus, you’d have to run: git remote set-url origin g...@github.com:zendtech/ZendOptimizerPlus.git on your clones for them to continue working. This is not related to the code that’s already inside the PHP tree. Zeev
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
Hi Nikita, I didn't get why do we need separate zend_std_compare() function. May be I just didn't look careful :) It would be great to look into the patch between master and current of your branch. It would be more clear than internal patches. Thanks. Dmitry. On Mon, May 13, 2013 at 2:50 PM, Nikita Popov wrote: > On Mon, May 13, 2013 at 12:25 PM, Dmitry Stogov wrote: > >> Would need an additional object handler though (as compare_objects >>> works only on objects, so it's currently not possible to support something >>> like $gmp == 0). >>> >> >> Or may be we may introduce additional opcode (or even pseudo-opcode) >> ZEND_CMP to do it in the same way. >> > I implemented it with a separate handler for now ( > https://github.com/nikic/php-src/commit/208442f84afd7ccd8e2dce8138c0950719a2e031), > but I'm also okay with moving it into do_operation. Not sure if it's a good > idea to add pseudo opcodes though. > > Nikita >
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Mon, May 13, 2013 at 12:25 PM, Dmitry Stogov wrote: > Would need an additional object handler though (as compare_objects works >> only on objects, so it's currently not possible to support something like >> $gmp == 0). >> > > Or may be we may introduce additional opcode (or even pseudo-opcode) > ZEND_CMP to do it in the same way. > I implemented it with a separate handler for now ( https://github.com/nikic/php-src/commit/208442f84afd7ccd8e2dce8138c0950719a2e031), but I'm also okay with moving it into do_operation. Not sure if it's a good idea to add pseudo opcodes though. Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
Hi, On Mon, May 13, 2013 at 1:24 PM, Nikita Popov wrote: > On Mon, May 13, 2013 at 7:49 AM, Dmitry Stogov wrote: > >> Hi Nikita, >> >> The patch looks quite good. >> However, it must slow down each comparison operator (even if it compares >> two integers). >> > In most cases it shouldn't, as the comparisons usually go through the > fast_is_*_functions, which have special handling for integers and doubles. > is_equal_function itself for example is only used in the implementation of > ZEND_CASE (why? shouldn't we use the fast_ one here too?) and stuff like > array_search. > Ahh, you are right :) > > I would suggest overloading of CMP operator instead of separate <, <=, ==, >> !=, >, >=. >> > > But yeah, that sounds like a better solution. The advantages I see: > a) It will automatically work with sorting functions (and other stuff > using compare_function). This is a pretty big plus. > b) You don't have to implement the same (or similar) code for four (or > six) operators. > c) It (at least partially) also solves the concerns raised by Sara. > I'm glad, you are agree :) > Would need an additional object handler though (as compare_objects works > only on objects, so it's currently not possible to support something like > $gmp == 0). > > Or may be we may introduce additional opcode (or even pseudo-opcode) ZEND_CMP to do it in the same way. Also it may be better to use a table of callbacks for each overloaded operand instead of single one that need to do switch anyway. Thanks. Dmitry. > Nikita >
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Mon, May 13, 2013 at 7:49 AM, Dmitry Stogov wrote: > Hi Nikita, > > The patch looks quite good. > However, it must slow down each comparison operator (even if it compares > two integers). > In most cases it shouldn't, as the comparisons usually go through the fast_is_*_functions, which have special handling for integers and doubles. is_equal_function itself for example is only used in the implementation of ZEND_CASE (why? shouldn't we use the fast_ one here too?) and stuff like array_search. I would suggest overloading of CMP operator instead of separate <, <=, ==, > !=, >, >=. > But yeah, that sounds like a better solution. The advantages I see: a) It will automatically work with sorting functions (and other stuff using compare_function). This is a pretty big plus. b) You don't have to implement the same (or similar) code for four (or six) operators. c) It (at least partially) also solves the concerns raised by Sara. Would need an additional object handler though (as compare_objects works only on objects, so it's currently not possible to support something like $gmp == 0). Nikita
Re: [PHP-DEV] Scalar Type Casting Magic Methods
On Wed, 2013-05-08 at 10:42 +0200, Ferenc Kovacs wrote: > 2013.05.08. 7:38, "Pierre du Plessis" ezt írta: > > > > The __toArray can be useful if you want to perform array functions on the > > object (E.G array_filter), otherwise I think it would be very useful if > > the This can't work. Consider Which method will be called? > > array functions can accept an object implementing ArrayAccess as well > > instead of just an array > > yeah, I also think that ArrayObjects should be accepted where array is > expected. Patches are certainly welcome, but be sure to get to every place, else it becomes an inconsistent mess :) Oh, and be consistent about return values of operations ... oh, and will $result = some_array_operation(new ArrayObject); return an array or instance of ArrayObject, if the later how will it be instantiated ... do we have to pass result factories or something to all of those? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
Hi! > I did not, it makes little difference. We agreed that new features go > to php-next not in next point release, avoiding the mess about > figuring out which one gets in which point release. No we did not agree to that. We never agreed to nothing being added in point releases at all, and it makes no sense. Waiting for a year and a major version to add a function is plain wrong. We agreed to not to add major features, and consider minor features on case-by-case basis. If you have a case why this feature not to be added - please feel free to state it. > In the case of openssl we have someone, even more than one, same for zip f.e. http://pecl.php.net/openssl does not exist. When it will be created and when first release is happening? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
