Re: [PHP-DEV] master is broken on Travis
On Thu, Aug 21, 2014 at 12:29 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Removed phpdbg build from configure, and master builds fine. Removed its tests as well to have travis finish green. Did you commit it? I see Travis CI build is still broken. Committed and it works, the build done at travis finished OK. But some of the tests fail: The command ./sapi/cli/php run-tests.php -p `pwd`/sapi/cli/php -g FAIL,XFAIL,BORK,WARN,LEAK,SKIP --show-diff --set-timeout 120 exited with 1. Still didn't check it. Kaplan
Re: [PHP-DEV] [VOTE] Abstract Syntax Tree
On Wed, Aug 20, 2014 at 3:41 PM, Levi Morrison le...@php.net wrote: On Wed, Aug 20, 2014 at 7:30 AM, Paul Dragoonis dragoo...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:32 AM, Andi Gutmans a...@zend.com wrote: Hi Nikita, I reviewed the AST RFC on my way to vote but there was something that wasn’t clear to me. This patch introduces some semantic/behavioral changes in addition to the AST. Are these as a side-effect of how AST was implemented? Or are they unrelated to the AST patch? I think some of them make sense but I’m having a bit of a hard time separating out the benefits of the AST (which I really like) and making other changes to semantics w/o really understanding if they are side-effects and we have no choice vs. we’re trying to solve for two separate items in one RFC. Any BC breaks here we think could bite us? Hi Nikita, I second some of Andi's concerns about behavioural changes, some things working from right-to-left and not left-to-right. Are these things that we can adapt the AST part or tweak another part to make this more consistent with previous versions of PHP. I just had a chat with Paul about this, and there was a misunderstanding about what this RFC actually does regarding left-to-right evaluation on list() constructs. I also saw this misunderstanding in a few other places, so it seems to be a common misunderstanding. Under the proposed changes as well as in PHP 5.x, the end result of the following is the same: list($a, $b) = array(1, 2); $a will be 1 and $b will be 2. Again, this hasn't changed. The difference is that in PHP 5.x the variable $b will be assigned 2 before $a is assigned 1; under these changes $a will be assigned 1 first and then $b will be assigned 2. I'm happy with this behaviour and agree that the AST version is what I would expect, my confusion was that I thought PHP 5.x was 1,2 and the AST was 2,1 which it of course is not the case. Now you could see why I raised concerns about this in the first place. This really only affects strange situations, such as ones listed in the RFC.
Re: [PHP-DEV] master is broken on Travis
Hi! Committed and it works, the build done at travis finished OK. Yes, I saw it, thanks. A number of tests on debug version have errors or segfaults or glibc memory errors. Somebody probably should look into this. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] master is broken on Travis
Hi Stas, Can you post the list of failed tests Thanks. Dmitry. On Thu, Aug 21, 2014 at 11:49 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Committed and it works, the build done at travis finished OK. Yes, I saw it, thanks. A number of tests on debug version have errors or segfaults or glibc memory errors. Somebody probably should look into this. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/
Re: [PHP-DEV] master is broken on Travis
Hi! Can you post the list of failed tests Can be seen here: https://travis-ci.org/php/php-src/jobs/33142160 the list isn't full because it times out now (also shows multiple ** ERROR: process timed out ** messages). If you look there for Segmentation fault or *** glibc detected *** you'll see many instances. Also something like this: 001+ Fatal error: Uncaught �,�J on Zend/tests/bug64821.3.phpt, which does not produce crash but clearly is a memory error and fails the test. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integer Semantics
On Tue, 19 Aug 2014, Andrea Faulds wrote: Good evening, I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics I think it is good to make sure it behaves the same on all systems. However, I think the behaviour should become what currently is the shift behaviour on the platform with our largest userbase: Linux on AMD64 with GCC. There is no reason to penalise people that well might have relied on some odd behaviour - possible even with good reasons. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple default cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the Uniform Variable Syntax, that I already `wrote about`_, the current discussion on `Binary String Comparison`_, and now changing the `behaviour`_ on and in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with But Symfony and ZendFramework don't use this either, as there is so much code out there As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science purity reasons to make things better have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. **Don't be Evil** cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
Hi, Thanks to Anatol and Pierre the 64-bit patch is ready https://github.com/weltling/php-src I made quick code review and don't see any technical problems now. The performance and memory consumption difference is negligible. see https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq3_jAiCeI2cGHJ3UtQ/edit#gid=0 The patch breaks one test on 32-bit Linux: ext/date/tests/bug53437_var3.phpt (seems to be a bogus test and wrong behavior in php5.6 and below) and one test on 64-bit Linux: ext/standard/tests/array/array_pad_variation2.phpt (has to be analyzed) The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I'm not sure how to proceed. If I'm alone, lets go ahead with new names. If some others prefer old names we will probably need voting. Despite of renaming, I would like to see this patch in master ASAP. Thanks. Dmitry.
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21 August 2014 08:30, Derick Rethans der...@php.net wrote: Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. **Don't be Evil** +1 on everything Derick said. I want to make one more point: if there's just one thing we learn from other languages that have made BC-breaking, major version transitions, it should be that library and framework authors will ultimately have to support both versions in the same code base. Python tried using tooling such as 2to3 to help manage the transition, but in the end the only way Python 3 has gotten any traction is libraries supporting both, which effectively means that library authors can only write the subset of Python that's supported by 2 and 3. Every time we break BC — in either of the ways Derick said — we narrow the subset of PHP 5 and PHP 7 that's available to people writing PHP code that has to work on both. If we narrow it too far, it'll be too unexpressive, or too hard to use, or just plain won't do something that they'll need, and PHP 7 will risk becoming this decade's Perl 6: the cautionary tale for what happens when you burn all the boats. PHP 7 is an opportunity. It needs to be one that we embrace, and take advantage of, but most importantly one that is evolutionary and allows our user base to come with us. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 18:23, Dmitry Stogov dmi...@zend.com wrote: The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I don’t like this. With the bigints patch and RFC, I want to keep IS_LONG and the word “long” to distinguish between what would be the two types of integer: * IS_LONG/long - 32-bit or 64-bit integer (machine-dependant) * IS_BIGINT/bigint - arbitrary-size integer * IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type) Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention is that “integer” and “int” are synonyms for “long or bigint”. However, if internally an int is one thing and to userland it’s another, that would be problematic. If this goes through, I’d probably make my bigints patch rename IS_INT to something new again, probably IS_SMALLINT or even back to IS_LONG. If it must be renamed, could it be something else? IS_LONGLONG perhaps? Seems stupid on the face of it, but it’s actually a C `long long` underneath, isn’t it? FWIW, I prefer Z_LLVAL to Z_IVAL. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21 Aug 2014, at 18:28, Adam Harvey ahar...@php.net wrote: Every time we break BC — in either of the ways Derick said — we narrow the subset of PHP 5 and PHP 7 that's available to people writing PHP code that has to work on both. If we narrow it too far, it'll be too unexpressive, or too hard to use, or just plain won't do something that they'll need, and PHP 7 will risk becoming this decade's Perl 6: the cautionary tale for what happens when you burn all the boats. Not all BC breaks prevent code from being both forwards- and backwards-compatible, however. In some cases, the new way to do something works correctly in old versions as well. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 8/21/14, 10:23 AM, Dmitry Stogov wrote: Hi, Thanks to Anatol and Pierre the 64-bit patch is ready https://github.com/weltling/php-src I made quick code review and don't see any technical problems now. The performance and memory consumption difference is negligible. see https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq3_jAiCeI2cGHJ3UtQ/edit#gid=0 The patch breaks one test on 32-bit Linux: ext/date/tests/bug53437_var3.phpt (seems to be a bogus test and wrong behavior in php5.6 and below) and one test on 64-bit Linux: ext/standard/tests/array/array_pad_variation2.phpt (has to be analyzed) The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I'm not sure how to proceed. If I'm alone, lets go ahead with new names. If some others prefer old names we will probably need voting. Despite of renaming, I would like to see this patch in master ASAP. Thanks. Dmitry. We have the code ready to go. The change was voted OK. I say merge it. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Aug 21, 2014 7:42 PM, Andrea Faulds a...@ajf.me wrote: On 21 Aug 2014, at 18:23, Dmitry Stogov dmi...@zend.com wrote: The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I don’t like this. With the bigints patch and RFC, I want to keep IS_LONG and the word “long” to distinguish between what would be the two types of integer: * IS_LONG/long - 32-bit or 64-bit integer (machine-dependant) * IS_BIGINT/bigint - arbitrary-size integer * IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type) Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention is that “integer” and “int” are synonyms for “long or bigint”. However, if internally an int is one thing and to userland it’s another, that would be problematic. If this goes through, I’d probably make my bigints patch rename IS_INT to something new again, probably IS_SMALLINT or even back to IS_LONG. If it must be renamed, could it be something else? IS_LONGLONG perhaps? Seems stupid on the face of it, but it’s actually a C `long long` underneath, isn’t it? FWIW, I prefer Z_LLVAL to Z_IVAL. The original patch used the right naming based on the type used behind it. In any case, the patch represents what the rfc and the discussions around it say. I rather merge it asal and begin on the (long) list of todos for 7. If you like to propose new naming with the bigint rfc, please go ahead. Time is also an issue as ppl are beginning to migrate their extensions to test. Changing them again takes time. Cheers, Pierre
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Aug 21, 2014 7:58 PM, Andrea Faulds a...@ajf.me wrote: On 21 Aug 2014, at 18:56, Pierre Joye pierre@gmail.com wrote: The original patch used the right naming based on the type used behind it. So IS_LONGLONG, then? The original patch, the one from last year. We have made compromises to fulfill other devs requests, three times. Now to be honest I would merge it right away. I do not see why we need to discuss that again. When I see how phpng got accepted without a word, time to stop arguing about such things. Merge and move back to code. If one thinks that one thing or another should be changed, in this patch or phpng, he will need to write a rfc (and not in 6 months :). In any case, the patch represents what the rfc and the discussions around it say. I rather merge it asal and begin on the (long) list of todos for 7. If you like to propose new naming with the bigint rfc, please go ahead. Time is also an issue as ppl are beginning to migrate their extensions to test. Changing them again takes time. Forgive me if I’m wrong, but wouldn’t changing the name again just be a simple matter of global find/replace? No, totally not :) Even less as bigint support should be added too. And if bigint support will be optional, the code will need more changes.
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 19:03, Pierre Joye pierre@gmail.com wrote: Now to be honest I would merge it right away. I do not see why we need to discuss that again. When I see how phpng got accepted without a word, time to stop arguing about such things. Merge and move back to code. If one thinks that one thing or another should be changed, in this patch or phpng, he will need to write a rfc (and not in 6 months :). This is a trivial name change. We have only once chance to get it right since the IS_* constants are used so, so widely. We should get it right now. Forgive me if I’m wrong, but wouldn’t changing the name again just be a simple matter of global find/replace? No, totally not :) Why wouldn’t it? Could you elaborate? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 18:56, Pierre Joye pierre@gmail.com wrote: The original patch used the right naming based on the type used behind it. So IS_LONGLONG, then? In any case, the patch represents what the rfc and the discussions around it say. I rather merge it asal and begin on the (long) list of todos for 7. If you like to propose new naming with the bigint rfc, please go ahead. Time is also an issue as ppl are beginning to migrate their extensions to test. Changing them again takes time. Forgive me if I’m wrong, but wouldn’t changing the name again just be a simple matter of global find/replace? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Aug 21, 2014 8:05 PM, Andrea Faulds a...@ajf.me wrote: On 21 Aug 2014, at 19:03, Pierre Joye pierre@gmail.com wrote: Now to be honest I would merge it right away. I do not see why we need to discuss that again. When I see how phpng got accepted without a word, time to stop arguing about such things. Merge and move back to code. If one thinks that one thing or another should be changed, in this patch or phpng, he will need to write a rfc (and not in 6 months :). This is a trivial name change. We have only once chance to get it right since the IS_* constants are used so, so widely. We should get it right now. Then please do a rfc, but we are not going to rewamp the patch for the 6th time. It has been accepted and we have been more than cooperative. Forgive me if I’m wrong, but wouldn’t changing the name again just be a simple matter of global find/replace? No, totally not :) Why wouldn’t it? Could you elaborate? I would instead to ask you to try to migrate a not so trivial extension :)
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
Every time we break BC — in either of the ways Derick said — we narrow the subset of PHP 5 and PHP 7 that's available to people writing PHP code that has to work on both. If we narrow it too far, it'll be too unexpressive, or too hard to use, or just plain won't do something that they'll need, and PHP 7 will risk becoming this decade's Perl 6: the cautionary tale for what happens when you burn all the boats. I agree with this idea principle. I disagree that these RFCs are breaking so much backwards compatibility to create the next Perl 6. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 19:08, Pierre Joye pierre@gmail.com wrote: Then please do a rfc, but we are not going to rewamp the patch for the 6th time. It has been accepted and we have been more than cooperative. Do we really need to delay this by three weeks? Forgive me if I’m wrong, but wouldn’t changing the name again just be a simple matter of global find/replace? No, totally not :) Why wouldn’t it? Could you elaborate? I would instead to ask you to try to migrate a not so trivial extension :) No, seriously. Why can’t a sed script be used to change a constant name? Can you tell me why that wouldn’t work? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
Pierre, wait a day, and if we won't have many developers, who against the new names - commit it as is. Thanks. Dmitry. On Thu, Aug 21, 2014 at 10:03 PM, Pierre Joye pierre@gmail.com wrote: On Aug 21, 2014 7:58 PM, Andrea Faulds a...@ajf.me wrote: On 21 Aug 2014, at 18:56, Pierre Joye pierre@gmail.com wrote: The original patch used the right naming based on the type used behind it. So IS_LONGLONG, then? The original patch, the one from last year. We have made compromises to fulfill other devs requests, three times. Now to be honest I would merge it right away. I do not see why we need to discuss that again. When I see how phpng got accepted without a word, time to stop arguing about such things. Merge and move back to code. If one thinks that one thing or another should be changed, in this patch or phpng, he will need to write a rfc (and not in 6 months :). In any case, the patch represents what the rfc and the discussions around it say. I rather merge it asal and begin on the (long) list of todos for 7. If you like to propose new naming with the bigint rfc, please go ahead. Time is also an issue as ppl are beginning to migrate their extensions to test. Changing them again takes time. Forgive me if I’m wrong, but wouldn’t changing the name again just be a simple matter of global find/replace? No, totally not :) Even less as bigint support should be added too. And if bigint support will be optional, the code will need more changes.
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 8/21/14, 11:09 AM, Levi Morrison wrote: Every time we break BC — in either of the ways Derick said — we narrow the subset of PHP 5 and PHP 7 that's available to people writing PHP code that has to work on both. If we narrow it too far, it'll be too unexpressive, or too hard to use, or just plain won't do something that they'll need, and PHP 7 will risk becoming this decade's Perl 6: the cautionary tale for what happens when you burn all the boats. I agree with this idea principle. I disagree that these RFCs are breaking so much backwards compatibility to create the next Perl 6. Cumulatively they could easily break BC in the way Derick mentioned. BC issues will mount up unless a higher level overview is considered about the release. -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 19:14, Dmitry Stogov dmi...@zend.com wrote: Pierre, wait a day, and if we won't have many developers, who against the new names - commit it as is. Perhaps none will be against it now, however, how will they feel when they have to change IS_INT in their extensions *again* to a new name bigints would necessarily introduce? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Aug 21, 2014 8:14 PM, Dmitry Stogov dmi...@zend.com wrote: Pierre, wait a day, and if we won't have many developers, who against the new names - commit it as is. Thanks. Dmitry. We have waited months due to phpng. We have waited months due to objection after the rfc was accepted already (2nd attempt). Why should we follow different rules than other RFCs? Bigint is a work in progress, there is no vote, there is not even a discussion on this list about it. Asking us to hang on again for yet another rfc is really not something I can live with.
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 19:21, Pierre Joye pierre@gmail.com wrote: Why should we follow different rules than other RFCs? Bigint is a work in progress, there is no vote, there is not even a discussion on this list about it. Asking us to hang on again for yet another rfc is really not something I can live with. There is a discussion on this list, but you have a point. I’ll consider either creating an RFC to rename it or finding some sort of workaround. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
I completely agree. Dmitry. On Thu, Aug 21, 2014 at 10:21 PM, Pierre Joye pierre@gmail.com wrote: On Aug 21, 2014 8:14 PM, Dmitry Stogov dmi...@zend.com wrote: Pierre, wait a day, and if we won't have many developers, who against the new names - commit it as is. Thanks. Dmitry. We have waited months due to phpng. We have waited months due to objection after the rfc was accepted already (2nd attempt). Why should we follow different rules than other RFCs? Bigint is a work in progress, there is no vote, there is not even a discussion on this list about it. Asking us to hang on again for yet another rfc is really not something I can live with.
[PHP-DEV] master/phpng has many Windows specific regressions (PHPT and Joomla)
Master (with PHPNG) builds on Windows (our snapshot build servers were never interrupted BTW), though extensions including PDO, mysql and soap are disabled. Master on Windows now has 201 test failures(all sapi scenarios) while Linux (for me at least) only has about 20 failures, see: http://qa.php.net/reports/db/PHP_MASTER/r0ac3d8d/PHPT_CMP_PHP_5_6-5.6.0RC3-TS-X86-VC11_Local-FileSystem_MySQL-5.6_CLI_v_PHP_Master-r0ac3d8d-TS-X86-VC.html Master is now all RED on qa.php.net, see: http://qa.php.net/pftt.php Additionally, for the CLI sapi scenario, there are many regressions of Joomla's PhpUnit test suites: typically I get a ~72% pass rate but now only get ~60% pass rate. See: http://qa.php.net/reports/db/PHP_MASTER/r0ac3d8d/PhpUnit_CMP_Joomla-Platform-12.3_PHP_Master-r0ac3d8d-TS-X86-VC11_Local-FileSyste.html Looks like Joomla regressions are mostly because of the deprecation of `iconv.internal_encoding` and missing the PDO extension. Pass rate for Symfony remains unchanged (~93%), see: http://qa.php.net/reports/db/PHP_MASTER/r0ac3d8d/PhpUnit_CMP_Symfony-Standard-2.1.8_PHP_Master-r0ac3d8d-TS-X86-VC11_Local-FileSys.html See list below for PHPT failures and analysis. Apparently I can't attach the run-test.php output or Joomla output. Some tests fail because expected output has changed (sapi and file failures) which I don't believe are actual functionality problems. Unless anyone disagrees that those tests are not actually ok, I'm going to file bug reports and update them (creating -win32 fork if needed). Some tests (array, reflection, session) could be a major regression. ; ; expected output didn't include the character encoding, which is now included by builtin web server Sapi\cli\tests\006.phpt Sapi\cli\tests\bug43177.phpt Sapi\cli\tests\bug61977.phpt Sapi\cli\tests\bug65066_100.phpt Sapi\cli\tests\bug65066_422.phpt Sapi\cli\tests\bug65066_511.phpt Sapi\cli\tests\bug65633.phpt Sapi\cli\tests\bug66830.phpt Sapi\cli\tests\bug67429.phpt Sapi\cli\tests\php_cli_server_004.phpt Sapi\cli\tests\php_cli_server_005.phpt Sapi\cli\tests\php_cli_server_006.phpt Sapi\cli\tests\php_cli_server_007.phpt Sapi\cli\tests\php_cli_server_008.phpt Sapi\cli\tests\php_cli_server_009.phpt Sapi\cli\tests\php_cli_server_010.phpt Sapi\cli\tests\php_cli_server_012.phpt Sapi\cli\tests\php_cli_server_015.phpt Sapi\cli\tests\php_cli_server_017.phpt Sapi\cli\tests\php_cli_server_018.phpt Sapi\cli\tests\php_cli_server_019.phpt ; ; expected reference count has changed Zend\tests\001.phpt Zend\tests\002.phpt Zend\tests\003.phpt Zend\tests\bug24773.phpt Zend\tests\bug35393.phpt Zend\tests\bug38047.phpt Zend\tests\bug40815.phpt Zend\tests\bug52361.phpt Zend\tests\bug54013.phpt Zend\tests\bug60825.phpt Zend\tests\bug63635.phpt Zend\tests\bug64515.phpt Zend\tests\bug67436\bug67436_nohandler.phpt Zend\tests\call_user_func_004.phpt Zend\tests\call_user_func_005.phpt Zend\tests\closure_018.phpt Zend\tests\closure_019.phpt Zend\tests\closure_026.phpt Zend\tests\dereference_002.phpt Zend\tests\fr47160.phpt Zend\tests\gc_014.phpt Zend\tests\gc_029_zts.phpt Zend\tests\gc_030.phpt Zend\tests\gc_032.phpt Zend\tests\generators\errors\non_ref_generator_iterated_by_ref_error.phpt Zend\tests\generators\generator_rewind.phpt Zend\tests\objects_027.phpt ; returning false ext\date\tests\009_win32.phpt ext\date\tests\DateTimeZone_verify.phpt ext\date\tests\DateTime_verify.phpt ext\date\tests\bug41523.phpt ext\date\tests\bug51866.phpt ext\date\tests\bug65184.phpt ext\date\tests\gmstrftime_basic.phpt ext\date\tests\gmstrftime_variation1.phpt ext\date\tests\gmstrftime_variation2.phpt ext\date\tests\gmstrftime_variation21 ext\date\tests\gmstrftime_variation3.phpt ext\date\tests\gmstrftime_variation4.phpt ext\date\tests\gmstrftime_variation5.phpt ext\date\tests\gmstrftime_variation6.phpt ext\date\tests\gmstrftime_variation7.phpt ext\date\tests\gmstrftime_variation8.phpt ext\date\tests\strftime_basic.phpt ext\date\tests\strftime_variation1.phpt ext\date\tests\strftime_variation2.phpt ext\date\tests\strftime_variation21.phpt ext\date\tests\strftime_variation23.phpt ext\date\tests\strftime_variation3.phpt ext\date\tests\strftime_variation4.phpt ext\date\tests\strftime_variation5.phpt ext\date\tests\strftime_variation6.phpt ext\date\tests\strftime_variation7.phpt ext\date\tests\strftime_variation8.phpt ext\hash\tests\hash_algos.phpt ext\hash\tests\hash_copy_001.phpt ext\iconv\tests\iconv_encoding_basic.phpt ext\iconv\tests\iconv_get_encoding_basic.phpt ext\iconv\tests\iconv_set_encoding_variation.phpt ext\iconv\tests\iconv_strpos_basic.phpt ext\iconv\tests\iconv_strpos_variation5.phpt ext\iconv\tests\iconv_strrpos_basic.phpt ext\pcre\tests\006.phpt ext\pcre\tests\recursion_limit.phpt ext\phar\tests\create_path_error.phpt ; ? ext\reflection\tests\009.phpt ext\reflection\tests\025.phpt ext\reflection\tests\ReflectionClass_getInterfaces_003.phpt ext\reflection\tests\ReflectionClass_getMethods_001.phpt ext\reflection\tests\ReflectionClass_getMethods_003.phpt
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
In worst case, we will always able to make a new RFC and rename them back, but I really don't like to delay this patch just because few people (including me) are not agree with names. RFC was already delayed for months, and actually, it was voted with section about new names. Thanks. Dmitry. On Thu, Aug 21, 2014 at 10:17 PM, Andrea Faulds a...@ajf.me wrote: On 21 Aug 2014, at 19:14, Dmitry Stogov dmi...@zend.com wrote: Pierre, wait a day, and if we won't have many developers, who against the new names - commit it as is. Perhaps none will be against it now, however, how will they feel when they have to change IS_INT in their extensions *again* to a new name bigints would necessarily introduce? -- Andrea Faulds http://ajf.me/
[PHP-DEV] master/phpng has many Windows specific regressions (PHPT and Joomla)
I'm sharing the run-test output for master/phpng on Windows here: http://131.107.220.66/PFTT-Results/Share/20140821/phpng_phpt_windows.txt Also, I'm sharing the Joomla phpunit output here: http://131.107.220.66/PFTT-Results/Share/20140821/phpunit_Joomla-Platform-12.3_Local-FileS.xml
Re: [PHP-DEV] master/phpng has many Windows specific regressions (PHPT and Joomla)
Hi Matt, it looks like you use phpt tests not from master branch. But anyway, master with phpng definitely has bugs and problems. I'll try to look into these tests more careful on next week, once big patches (int64 and AST) are merged. Thanks. Dmitry. On Thu, Aug 21, 2014 at 10:35 PM, Matt Ficken themattfic...@gmail.com wrote: I'm sharing the run-test output for master/phpng on Windows here: http://131.107.220.66/PFTT-Results/Share/20140821/phpng_phpt_windows.txt Also, I'm sharing the Joomla phpunit output here: http://131.107.220.66/PFTT-Results/Share/20140821/phpunit_Joomla-Platform-12.3_Local-FileS.xml
Re: [PHP-DEV] [VOTE][RFC] Closure::apply() (re-opening)
I suppose calling it statically a user would probably want to recycle the same function/closure, so binding/calling it real time would have little impact if done properly. On Wed, Aug 20, 2014 at 2:30 PM, Levi Morrison le...@php.net wrote: On Wed, Aug 20, 2014 at 11:51 AM, Nathan nathan.br...@starin.biz wrote: The only thing I'd suggest is like I said in the last email is to make the syntax more like Closure::bind(Closure $closure, object $newThis, [mixed $newScope = 'static']) and make it Closure::apply(mixed $newObjectOrScope [, mixed ... $parameters]) $newObjectOrScope would then allow a user to supply a class name or an object. If class name is passed you have access to static::, self::, and parent:: inside the function everything else works as described in the RFC. Give the ability to call a closure as a static method of a class or a normal method of an object. Right now the only way to do it is doing binding and creating new closures and calling those closures then destroying them. I think you are confused. This proposal basically binds the closure to the new object and invokes it immediately. I genuinely don't see how it being statically bound to the object will make a difference. Please elaborate.
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
What if we were to *quantify* backwards compatibility in a way, as opposed to just discussing the hypothetical BC breaking potential of a change? I've never thought of this before, but this discussion had me thinking... When I write a library that has a large user base, I try to write as many unit tests and potential regression tests as possible. Unfortunately, the larger the user base and the larger the feature set, the more coverage is necessary. A language like PHP, it would be nearly unlimited. But stay with me here. What's better than a simple unit of testing or benchmarking? Most of us know that not much really beats real world application testing, or at least a more realistic form of feature use. This is where the Hack team got it right. Hack, during its early development (and even still) used a suite of PHP frameworks, libraries, and well known projects to test their PHP compatibility. Ironically, I believe that Hack originally used these types of test due to a lack of a language specification: there was no other way to really make sure to match the language's behavior. However I think that this type of testing is valuable anyway. What if we were to create a (or borrow Hack's) framework testing suite and run PHP 7 and upcoming RFC patches against the suite before accepting them. Yes, likely things will fail with BC breaks, but then the PHP internals team (or the RFC writer, hopefully) could then see exactly what was being used in a given framework that might break. Even better, the internals/RFC developer could see how much effort would be required to fix the BC break in the broken tested framework and could gauge whether the break was worthwhile or not a lot more. Finally, even more importantly, we could see the range of libraries and frameworks that would break with a given change and even introduce a potential RFC rule for BC breaking (on major versions, etc)... like we have with rules around certain voting majorities based on the type of language change, we could have a certain percentage of libs/frameworks that would have to be compatible (or somehow quantify the effort needed to update each [can it be automated via a tool or not]). Anyway, just spit balling here. I know it would take effort, but this could make a huge difference in our oops moments and quality checking for the language updates. Hell, maybe it would even make us more apt to greenlight features that we'd otherwise be afraid of because we'd see that it wouldn't be as big of a deal as we thought. Overall I think this would reduce a lot of the conjecture and discussion/fear around possible BC breaks that could help or hurt the project and the future of the language. *Trevor Suarez* +Trevor Suarez https://plus.google.com/+TrevorSuarez @trevorsuarez https://twitter.com/trevorsuarez On Thu, Aug 21, 2014 at 2:17 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. I agree. Major means we *can* break BC, if there's a reason good enough, but that doesn't mean we get to break BC *for free*. We do need to carefully weight it each time and ensure it is worth it, not dismiss it with oh, it's PHP 7, so we can do anything we want, BC is no longer a concern. We have millions of people using PHP 5, and the goal is for almost all of them to eventually use PHP 7, otherwise there's no point in it. Each BC break creates another hurdle on the way to it. We should take it seriously. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On 21.08.2014 17:30, Derick Rethans wrote: On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple default cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the Uniform Variable Syntax, that I already `wrote about`_, the current discussion on `Binary String Comparison`_, and now changing the `behaviour`_ on and in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with But Symfony and ZendFramework don't use this either, as there is so much code out there As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science purity reasons to make things better have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. Derick, I'm on you if you say Please think really careful when you suggest to break Backwards Compatibility. It's very important in so much ways. *BUT* you are very unlikely in the cost of the 2 RFCs. First I don't see an comment of you in the Binary String Comparison RFC and I think you should do your misgivings there instead of wring this untopic. Each BC break should be discussed carefully by it's own! Marc **Don't be Evil** cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On Thu, Aug 21, 2014 at 8:30 AM, Derick Rethans der...@php.net wrote: On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple default cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the Uniform Variable Syntax, that I already `wrote about`_, the current discussion on `Binary String Comparison`_, and now changing the `behaviour`_ on and in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with But Symfony and ZendFramework don't use this either, as there is so much code out there As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science purity reasons to make things better have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. **Don't be Evil** cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Derick, I think you misunderstood my meaning. It was never my intention to imply that BC doesn't matter or that it should be taken lightly. My statement that it's not an issue was in the context of this RFC, which people seem to overwhelmingly agree is a good idea. When you have a beneficial idea that people like, implemented in a major version increment, BC is not an issue. That's what I meant and I stand by that. That said, I don't disagree with your larger points about BC being a consideration even in major release increments. However, I also feel the need to point out that, historically, there have been a lot of known issues in PHP that we've decided not to fix even in major increments because of what I believe to be an excess of BC concern. One example-- it's almost a cliche at this point-- is the inconsistent function naming and argument orders. In my experience, that's been the most common complaint I hear from PHP devs. We've avoided cleaning that up because it would break all kinds of stuff. While I agree that BC should never be decided on lightly, I do believe that an expectation exists that significant code updates will have to be made by framework/etc maintainers when upgrading to a new major release. So I do think we should allow ourselves to finally correct these lingering issues for the next major release. It will slow adoption in the short-term, but it is the right strategy for the language in the long-term. TL;DR: BC does matter and should never be taken lightly, but we should also not be afraid to introduce some BC in a major release in order to correct various longstanding issues. --Kris
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Thu, Aug 21, 2014 at 7:23 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, Thanks to Anatol and Pierre the 64-bit patch is ready https://github.com/weltling/php-src I made quick code review and don't see any technical problems now. The performance and memory consumption difference is negligible. see https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq3_jAiCeI2cGHJ3UtQ/edit#gid=0 The patch breaks one test on 32-bit Linux: ext/date/tests/bug53437_var3.phpt (seems to be a bogus test and wrong behavior in php5.6 and below) and one test on 64-bit Linux: ext/standard/tests/array/array_pad_variation2.phpt (has to be analyzed) The only thing that I don't like is a massive renaming described here https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings IS_LONG - IS_INT Z_LVAL - L_IVAL etc On one hand using INT may be more consistent, on the other hand it's going to break habits and make addition headache for merging from php-5 (I know, phpng already made problems) I'm not sure how to proceed. If I'm alone, lets go ahead with new names. If some others prefer old names we will probably need voting. Despite of renaming, I would like to see this patch in master ASAP. Thanks. Dmitry. I am against merging this with the long-int rename everywhere. This seems like change for the sake of change. I am also concerned that we now have zend_uint_t (a 64-bit integer type) and zend_uint (a 32-bit integer type). Notice the difference? Yes, it's the missing _t. I would appreciate it if we could consider the following naming convention: * zend_(u)int - 32 bit integer type * zend_(u)long - 64 bit integer type (on 64 bit systems) This retains the original meaning of the type, with the tweak that zend_(u)long will be 64bit on LLP64 systems as well. This avoids the confusion of having two types that only differ by a _t suffix and have totally different meanings. It also removes any need to rename everything from LONG to INT. Thanks, Nikita
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On 21 Aug 2014, at 21:49, Nikita Popov nikita@gmail.com wrote: I am also concerned that we now have zend_uint_t (a 64-bit integer type) and zend_uint (a 32-bit integer type). Notice the difference? Yes, it's the missing _t. I would appreciate it if we could consider the following naming convention: * zend_(u)int - 32 bit integer type * zend_(u)long - 64 bit integer type (on 64 bit systems) This retains the original meaning of the type, with the tweak that zend_(u)long will be 64bit on LLP64 systems as well. This avoids the confusion of having two types that only differ by a _t suffix and have totally different meanings. It also removes any need to rename everything from LONG to INT. I was wondering if zend_uint was still 32-bit like I thought it was. I guess I mistook zend_uint_t for zend_uint, which backs up your (implied?) point about confusion. Your proposal sounds like a great idea, I’d be very in favour of this. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
On Thu, 21 Aug 2014, Marc Bennewitz wrote: On 21.08.2014 17:30, Derick Rethans wrote: On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. snip Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. snip I'm on you if you say Please think really careful when you suggest to break Backwards Compatibility. It's very important in so much ways. *BUT* you are very unlikely in the cost of the 2 RFCs. The cost? First I don't see an comment of you in the Binary String Comparison RFC and I think you should do your misgivings there instead of wring this untopic. Each BC break should be discussed carefully by it's own! Because it's not worth my time. I don't feel it necessary to comment if so many people already have spoken out against it: Julien[1], Sara[2], Rasmus[3], Adrian[4], Johannes[5]. Frankly, I don't understand why you haven't given up on this as nobody has shown support. [1] http://news.php.net/php.internals/76639 [2] http://news.php.net/php.internals/76613 [3] http://news.php.net/php.internals/76615 [4] http://news.php.net/php.internals/76614 [5] http://news.php.net/php.internals/76658 cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Binary String Comparison
On 17 Aug 2014, at 20:58, Marc Bennewitz php@mabe.berlin wrote: I've created a draft RFC and patch to change the behavior of non-strict string to string comparison to be binary safe (as the strict comparison operator does): https://wiki.php.net/rfc/binary_string_comparison On comparing two numeric strings both operands will be equal if the string representation will be the same. On comparing two numeric strings the first operand will be greater if the first not matching byte will be higher. On comparing two numeric strings the first operand will be lower if the first not matching byte will be lower. I might as well point out that I am also not in favour of this. In PHP, we *usually* do the Perl-like thing and pretend ints, floats and numeric strings are the same. This RFC reduces the extent to which we do that, meaning PHP would be less consistent. For that reason, I cannot support it. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64-bit integers and 64-bit string length patch is ready to be merged
On Aug 21, 2014 10:49 PM, Nikita Popov nikita@gmail.com wrote: I am against merging this with the long-int rename everywhere. This seems like change for the sake of change. It is accepted and ready to be merged. I am also concerned that we now have zend_uint_t (a 64-bit integer type) and zend_uint (a 32-bit integer type). Notice the difference? Yes, it's the missing _t. I would appreciate it if we could consider the following naming convention: * zend_(u)int - 32 bit integer type * zend_(u)long - 64 bit integer type (on 64 bit systems) The original patch used int32 and int64, _t. Was rejected because too much changes. I was even more strict in the very first version by using only stdint types and no alias or random names. Rejected as well. Long means absolutely nothing in term of integer size. We should ban its usage. So I am against anything using long. That being said: - patch will be merged. Most likely tomorrow - if minor tweaks like the uint one you refer are necessary, and that one makes sense, it can be done later Now, I asked everyone to stop applying or trying to apply double standards. Thanks. Cheers, Pierre
Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)
Hey: On Thu, Aug 21, 2014 at 11:30 PM, Derick Rethans der...@php.net wrote: On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote: On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: I have made an RFC which would make some small changes to how integers are handled, targeted at PHP 7: https://wiki.php.net/rfc/integer_semantics Thoughts and questions are appreciated. Thanks! snip And since you're targetting the next major release, BC isn't an issue. This sort of blanket statements that Backwards Compatibility is not an issue with a new major version is extremely unwarranted. *Extreme care* should be taken when deciding to break Backwards Compatibility. It should not be oh we have a major new version so we can break all the things™. There are two main types of breaking Backwards Compatibility: 1. The obvious case where running things trough ``php -l`` instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple default cases, it's a fricking bug fix too). 2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the Uniform Variable Syntax, that I already `wrote about`_, the current discussion on `Binary String Comparison`_, and now changing the `behaviour`_ on and in a subtle way. These changes are *not okay*, because they are nearly impossible to test for. Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the ``$`` in front of variables to ``£`` is a better change, as it's *immediately* apparent that stuff changed. And you can't get away with But Symfony and ZendFramework don't use this either, as there is so much code out there I am totally agree with Derick here. We should avoid to change such basic behaves.. thanks As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science purity reasons to make things better have little to no meaning for PHP, as it's clearly not designed in the first place. Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding and is not one of those, and subtle changes to what syntax means is certainly not one of them. **Don't be Evil** cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
