# [VOTE] 64 bit platform improvements for string length and integer - Thread: https://externals.io/message/71649 - Original archive: https://news-web.php.net/php.internals/71649 - Started by Anatol Belski on 2014-01-27T20:15:35+00:00 - Messages: 82 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/71649.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #71649 — Anatol Belski — 2014-01-27T20:15:35+00:00 URL: https://externals.io/message/71649#71649 https://wiki.php.net/rfc/size_t_and_int64 There was two big questions regarding the compatibility. Those open questions appeared in the discussions are reflected in the reworked RFC. First question, the possibility to keep the old zend_parse_parameters() specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the old zpp specs will for sure minimize the porting effort for the PECL extensions, but might lead to confusion (like people might think ‘l’ still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported. Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc. The reason for such renamings was to ensure source level incompatibility on compile time. However this might have a negative effect on the porting effort (despite the porting tools). Please use the yes/no Vote 2 to decide whether the old macro names have to be kept. The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are merely to decide about the semantical replacements choosen for the patch. Should the Votes 2 and 3 result in reverting of that semantical changes, the essential patch part about the 64 bit support will not be hurt. Reverting to old macro names or zpp specs is only the naming issue. Removal of the dead SAPIs is isolated in a separate RFC and can be considered to another time. Thanks for the constructive discussions on this RFC, support and testing. The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03 February 2014, 21:30 CET. --- ## #71696 — Nikita Popov — 2014-01-28T20:23:53+00:00 URL: https://externals.io/message/71649#71696 · In reply to: #71649 > https://wiki.php.net/rfc/size_t_and_int64 > > There was two big questions regarding the compatibility. Those open > questions appeared in the discussions are reflected in the reworked RFC. > > First question, the possibility to keep the old zend_parse_parameters() > specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the > old zpp specs will for sure minimize the porting effort for the PECL > extensions, but might lead to confusion (like people might think 'l' still > expects 'long' and not 'php_int_t'). Please use the yes/no Vote 3 to > decide whether the 'l', 'L', 's', 'p' have to stay supported. > > Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc. > The reason for such renamings was to ensure source level incompatibility > on compile time. However this might have a negative effect on the porting > effort (despite the porting tools). Please use the yes/no Vote 2 to decide > whether the old macro names have to be kept. > > The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are > merely to decide about the semantical replacements choosen for the patch. > Should the Votes 2 and 3 result in reverting of that semantical changes, > the essential patch part about the 64 bit support will not be hurt. > Reverting to old macro names or zpp specs is only the naming issue. > > Removal of the dead SAPIs is isolated in a separate RFC and can be > considered to another time. > > Thanks for the constructive discussions on this RFC, support and testing. > The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03 > February 2014, 21:30 CET. > Just to clarify my vote: I voted "No" on the RFC, but only because I think the major extension source API break is better suited to PHP 6 than PHP 5.6. I fully support merging this into master, as the first change for PHP 6. Nikita --- ## #71698 — Pierre Joye — 2014-01-28T20:33:13+00:00 URL: https://externals.io/message/71649#71698 · In reply to: #71696 > > > > […] > > Just to clarify my vote: I voted "No" on the RFC, but only because I think > the major extension source API break is better suited to PHP 6 than PHP > 5.6. I fully support merging this into master, as the first change for PHP > 6. Sad. As the work for pecl extensions is really not as large as you think, fairly straight forward. The vote for php6 is not running now. There is no option for PHP 6 as what can be done in php 6 internally is much larger and would allow more breakage. On the other side, we provide options to minimize the work for the extensions developers in order of magnitude smaller than the changes we introduced in the past for the OO APIs for example. Anyway, sad that you voted no for something as important than true 64bit support. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #71699 — Martin Keckeis — 2014-01-28T20:36:42+00:00 URL: https://externals.io/message/71649#71699 · In reply to: #71696 Am 28.01.2014 21:24 schrieb "Nikita Popov" : > > > > > […] still > > […] porting > > […] decide > > […] patch. > > […] testing. > > […] > > Just to clarify my vote: I voted "No" on the RFC, but only because I think > the major extension source API break is better suited to PHP 6 than PHP > 5.6. I fully support merging this into master, as the first change for PHP > 6. > > Nikita Sadly... (From a long waiting Php user, who dont want to wait 2-3 years...) --- ## #71700 — Nikita Popov — 2014-01-28T20:51:13+00:00 URL: https://externals.io/message/71649#71700 · In reply to: #71698 > > […] > think > > […] > PHP > > […] > > Sad. As the work for pecl extensions is really not as large as you > think, fairly straight forward. The vote for php6 is not running now. > There is no option for PHP 6 as what can be done in php 6 internally > is much larger and would allow more breakage. On the other side, we > provide options to minimize the work for the extensions developers in > order of magnitude smaller than the changes we introduced in the past > for the OO APIs for example. Anyway, sad that you voted no for > something as important than true 64bit support. > Maybe I'm indeed overestimating the impact. Could you please link to the source-code for a PECL (or other third-party) extension that was ported to be compatible with the new API, so people can see the actual impact this makes? (Hopefully some ext that requires compat across multiple versions like 5.3+ and has non-trivial amount of code and functions, like a few dozen.) I couldn't find an example in RFC, but maybe I just missed it. Only saw small snippets in there. Nikita --- ## #71701 — Christopher Jones — 2014-01-28T20:56:46+00:00 URL: https://externals.io/message/71649#71701 · In reply to: #71699 > Am 28.01.2014 21:24 schrieb "Nikita Popov" : > > […] > still > > […] > porting > > […] > decide > > […] > patch. > > […] > testing. > > […] > > Sadly... > (From a long waiting Php user, who dont want to wait 2-3 years...) > The extension compatibility issue is not insignificant. Each voter will have a different idea of how best to take PHP forward while keeping the current user base happy. Personnaly, I'd be glad to see the size_t_and_int64 vote halted until PHP 6 is discussed a little more. This would give a clearer idea of what BC breakages are likely in each release, and what the various release timeframes are. If the PHP 6 discussion doesn't happen or conclude quickly, then the size_t_and_int64 vote can be restarted in time for any merge to 5.6. Work on size_t_and_int64 and SAPI obsoletion etc should continue ready for which ever branch it will be merged to. I think I'm the only one (outside Anatol et al) actively looking at an extension the new branch and have committed to it. I've some more OCI8 patches pending, and more investigation to do. And then the extension needs to be made compatible with older PHP releases. In summary: migration is not a search and replace operation. Chris -- christopher.jones@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #71702 — Christopher Jones — 2014-01-28T21:08:23+00:00 URL: https://externals.io/message/71649#71702 · In reply to: #71700 > > > > […] > > Maybe I'm indeed overestimating the impact. Could you please link to the > source-code for a PECL (or other third-party) extension that was ported to > be compatible with the new API, so people can see the actual impact this > makes? (Hopefully some ext that requires compat across multiple versions > like 5.3+ and has non-trivial amount of code and functions, like a few > dozen.) I couldn't find an example in RFC, but maybe I just missed it. Only > saw small snippets in there. > > Nikita > You could do a diff with OCI8 on str_size_and_int64 vs. master to see one example. I also have some additional unmerged patches related to a comment you may see "/* XXX we assume that zend-zval len has 4 bytes */" since the zval len is now a size_t and no longer 32 bits. I have more investigation to do. If the ZPP specs are not portable (vote #3), an additional 53 calls to it will need #ifdef'ing so the code base is portable to older PHP releases (because OCI8 is also released on PECL). Chris -- christopher.jones@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #71717 — Jan Ehrhardt — 2014-01-29T08:41:33+00:00 URL: https://externals.io/message/71649#71717 · In reply to: #71701 Christopher Jones in php.internals (Tue, 28 Jan 2014 12:56:46 -0800): >I think I'm the only one (outside Anatol et al) actively looking at an >extension the new branch and have committed to it. I've some more >OCI8 patches pending, and more investigation to do. And then the >extension needs to be made compatible with older PHP releases. In >summary: migration is not a search and replace operation. I ported the php-ffmpeg extension (not even PECL) to the new branch by doing some simple search-and-replaces. I did this as a proof of concept that the extension would survive he change. At the moment I have two versions of the code, but it should be simple to merge the two versions with some #ifdef's. Jan --- ## #71803 — Marc Bennewitz — 2014-01-30T19:53:31+00:00 URL: https://externals.io/message/71649#71803 · In reply to: #71649 Hi Anatol, As of renaming LONG to INT there is one small inconsistence in the RFC: - ZEND_STRTOL/ZEND_STRTOUL should be ZEND_STRTOI/ZEND_STRTOUI - SIZEOF_ZEND_INT should be ZEND_INT_SIZEOF to be consistent with ZEND_INT_MAX/ZEND_INT_MIN/ZEND_UINT_MAX And in my opinion if we go to rename LONG to INT with BC we should also rename DOUBLE to FLOAT :) Marc > https://wiki.php.net/rfc/size_t_and_int64 > > There was two big questions regarding the compatibility. Those open > questions appeared in the discussions are reflected in the reworked RFC. > > First question, the possibility to keep the old zend_parse_parameters() > specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the > old zpp specs will for sure minimize the porting effort for the PECL > extensions, but might lead to confusion (like people might think ‘l’ still > expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to > decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported. > > Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc. > The reason for such renamings was to ensure source level incompatibility > on compile time. However this might have a negative effect on the porting > effort (despite the porting tools). Please use the yes/no Vote 2 to decide > whether the old macro names have to be kept. > > The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are > merely to decide about the semantical replacements choosen for the patch. > Should the Votes 2 and 3 result in reverting of that semantical changes, > the essential patch part about the 64 bit support will not be hurt. > Reverting to old macro names or zpp specs is only the naming issue. > > Removal of the dead SAPIs is isolated in a separate RFC and can be > considered to another time. > > Thanks for the constructive discussions on this RFC, support and testing. > The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03 > February 2014, 21:30 CET. --- ## #71806 — Anatol Belski — 2014-01-30T21:52:22+00:00 URL: https://externals.io/message/71649#71806 · In reply to: #71803 Hi Marc, thanks for the comments. > Hi Anatol, > > > As of renaming LONG to INT there is one small inconsistence in the RFC: > - ZEND_STRTOL/ZEND_STRTOUL should be ZEND_STRTOI/ZEND_STRTOUI Sounds logic, as despite ZEND_STRTOL maps strtol(), zend_int_t for instance also not necessarily 'int' literally. Just that the RFC is already being voted ... > - SIZEOF_ZEND_INT should be ZEND_INT_SIZEOF to be consistent with > ZEND_INT_MAX/ZEND_INT_MIN/ZEND_UINT_MAX > This descends from things like SIZEOF_LONG and so on, so completely legit for a C source. > And in my opinion if we go to rename LONG to INT with BC we should also > rename DOUBLE to FLOAT :) > Well, total renames was not the primary goal of this RFC. The renames suggested are to reflect what's going on in the patch and to break compilation with incompatible sources. Such topic asks for a new RFc :) Regards Anatol --- ## #71809 — Derick Rethans — 2014-01-30T23:56:23+00:00 URL: https://externals.io/message/71649#71809 · In reply to: #71649 > https://wiki.php.net/rfc/size_t_and_int64 > > There was two big questions regarding the compatibility. Those open > questions appeared in the discussions are reflected in the reworked RFC. Okay, so I've just looked at your attempt to port the MongoDB driver to the "size_t" branch: https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master And seriously, this one of the biggest mistakes I've seen in a while. Changing APIs so much that basically half of your code needs an update, or #ifdef hell. This is not acceptable, especially not for a PHP 5.X branch — especially not so late in the game for 5.6! And what is the gain? Absolutely nothing important. Who cares whether you can have 2147483648 or 9223372036854775808 byte long strings? Or whether some silly OS doesn't implement 64bit ints. Seriously, you are forgetting how incredible much pain *all* extension authors have to go through. This is not only ext/ or pecl/ or people hosting things in GitHub, but also an enormous amount of internal extensions for companies. No, there is way too little benefit here to push that gigantuous amount of work on developers, for zero to no gain. Atleast the introduction of a unicode string type (à la "PHP 6") had a useful meaning. I can't believe any sensible developer would vote to add this now into 5.6. 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 --- ## #71810 — Christopher Jones — 2014-01-31T00:38:59+00:00 URL: https://externals.io/message/71649#71810 · In reply to: #71649 > https://wiki.php.net/rfc/size_t_and_int64 > > There was two big questions regarding the compatibility. Those open > questions appeared in the discussions are reflected in the reworked RFC. > > First question, the possibility to keep the old zend_parse_parameters() > specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the > old zpp specs will for sure minimize the porting effort for the PECL > extensions, but might lead to confusion (like people might think ‘l’ still > expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to > decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported. > > Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc. > The reason for such renamings was to ensure source level incompatibility > on compile time. However this might have a negative effect on the porting > effort (despite the porting tools). Please use the yes/no Vote 2 to decide > whether the old macro names have to be kept. > > The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are > merely to decide about the semantical replacements choosen for the patch. > Should the Votes 2 and 3 result in reverting of that semantical changes, > the essential patch part about the 64 bit support will not be hurt. > Reverting to old macro names or zpp specs is only the naming issue. > > Removal of the dead SAPIs is isolated in a separate RFC and can be > considered to another time. > > Thanks for the constructive discussions on this RFC, support and testing. > The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03 > February 2014, 21:30 CET. > > Hi Anatol, A quick question: am I right to assume that because this vote has widespread impact on PHP it needs 2/3 majority per https://wiki.php.net/rfc/voting ? It's not totally clear that the change is covered by any of the examples in the voting RFC, but I see the 64 bit project as affecting the language as a whole (for better or worse!) Chris PS I've updated the RFC template to remind authors to state the acceptance criteria in the RFC. -- christopher.jones@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html --- ## #71811 — Stas Malyshev — 2014-01-31T00:42:41+00:00 URL: https://externals.io/message/71649#71811 · In reply to: #71809 Hi! > Okay, so I've just looked at your attempt to port the MongoDB driver to > the "size_t" branch: > https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master > > And seriously, this one of the biggest mistakes I've seen in a while. > Changing APIs so much that basically half of your code needs an update, > or #ifdef hell. This is not acceptable, especially not for a PHP 5.X > branch — especially not so late in the game for 5.6! Yeah, I looked at that patch and also at the diff between what replace.php produces and what is the end result, and it kind of worries me. Especially the part when you have to manually update all the types and how easy it is to miss one. Not sure, if this is solved automatically then I might be overreacting but right now it looks like I, for example, have been underestimating the amount of code disruption this is causing. I think refactoring PHP types and cleaning them up is a good idea, but it also means I can't recommend 5.6 adoption to anybody for years after the release, after we're sure extensions that were disrupted are stable again. And we're not on stellar numbers with 5.5 adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth ride unless you mess with opcodes. Again, I'm not against the idea of the patch or the implementation, but looking at how much work it seems to take for ext author, I'd say it may be a good start for PHP 6 branch. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #71815 — Anatol Belski — 2014-01-31T03:31:46+00:00 URL: https://externals.io/message/71649#71815 · In reply to: #71809 On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote: > > > > […] > > Okay, so I've just looked at your attempt to port the MongoDB driver to > the "size_t" branch: > https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master > I never said that were the full worky port. I did that in 2 hours as it was asked to be done on some extension, and you know that. It can be got ready in several days. So I've chosen this as an example on what the effort could be. Should I have taken an easy one with 5 minutes effort, like scream? But you prefer to interpret some complex case as an average one. > And seriously, this one of the biggest mistakes I've seen in a while. > Changing APIs so much that basically half of your code needs an update, > or #ifdef hell. This is not acceptable, especially not for a PHP 5.X > branch — especially not so late in the game for 5.6! > > And what is the gain? Absolutely nothing important. Who cares whether > you can have 2147483648 or 9223372036854775808 byte long strings? Or > whether some silly OS doesn't implement 64bit ints. Seriously, you are > forgetting how incredible much pain *all* extension authors have to go > through. This is not only ext/ or pecl/ or people hosting things in > GitHub, but also an enormous amount of internal extensions for > companies. So with next major you mean you would abandon the 5.x support in your exts, as it's too much? Reverting the semantic changes is a wimp. The effort you're talking about is a one time action, or can you point to another RFC of such globality? Without effort even a cat isn't getting born :) The compatibility path is being developed and improved, and it will be of course nothing without your as well as everyone's else participation. But you're right, who cares? > No, there is way too little benefit here to push that gigantuous amount > of work on developers, for zero to no gain. Atleast the introduction of > a unicode string type (à la "PHP 6") had a useful meaning. > > I can't believe any sensible developer would vote to add this now into > 5.6. It was started to have it consistent overall. The next step after it were the performance improvement on 64 bit. Then one could think about the dependency libs improvement. To whose costs goes this delay? Technically, as well as socially. Just because it's not getting done. It is a technical debt which is growing every day. Would I see that done berofe I'm retired, or would my grandkids at least? Suppressing things doesn't improve anything. Regards Anatol --- ## #71817 — Pierre Joye — 2014-01-31T04:57:09+00:00 URL: https://externals.io/message/71649#71817 · In reply to: #71809 > And seriously, this one of the biggest mistakes I've seen in a while. > Changing APIs so much that basically half of your code needs an update, > or #ifdef hell. This is not acceptable, especially not for a PHP 5.X > branch — especially not so late in the game for 5.6! Late? > And what is the gain? Absolutely nothing important. Who cares whether > you can have 2147483648 or 9223372036854775808 byte long strings? Or > whether some silly OS doesn't implement 64bit ints. Please re read the discussions about this RFC and the RFC, it is not only about that. If there is something still unclear, please raise your questions. > Seriously, you are > forgetting how incredible much pain *all* extension authors have to go > through. This is not only ext/ or pecl/ or people hosting things in > GitHub, but also an enormous amount of internal extensions for > companies. I do not think it has been forgotten. And many of the voters maintain (many) extensions as well, so do I. Cheers, Pierre --- ## #71839 — Derick Rethans — 2014-01-31T11:06:01+00:00 URL: https://externals.io/message/71649#71839 · In reply to: #71815 > On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote: > > […] > I never said that were the full worky port. I did that in 2 hours as it > was asked to be done on some extension, and you know that. It can be got > ready in several days. "Several days" for one extension. Imagine that you maintain a dozen. Are you really expecting that people will like it to have to spend a month porting all their extensions for such a marginal benefit? And that for a *minor* release? > So I've chosen this as an example on what the effort could be. Should > I have taken an easy one with 5 minutes effort, like scream? But you > prefer to interpret some complex case as an average one. Seriously, the MongoDB extension isn't that complicated. There are a lot of methods, but no different from any other database extension. > > […] > > So with next major you mean you would abandon the 5.x support in your > exts, as it's too much? No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I even support 5.1 for Xdebug. But with this change, the 5.6 compatible code is drastically different from the 5.2-5.5 ones. > > […] > > It was started to have it consistent overall. The next step after it > were the performance improvement on 64 bit. Then one could think about > the dependency libs improvement. To whose costs goes this delay? > Technically, as well as socially. Just because it's not getting done. > It is a technical debt which is growing every day. Uhm, the current situation works just fine. I wouldn't call this technical debt. I am also not saying that this branch is not a good thing—but so would be "consistent function naming" or "case sensitive function/method names"—and we're not never going to get these either. 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 --- ## #71840 — Derick Rethans — 2014-01-31T11:06:54+00:00 URL: https://externals.io/message/71649#71840 · In reply to: #71817 > > > > […] > > Late? Yes, in case you didn't know, 5.6 already has a release: http://www.php.net/archive/2014.php#id2014-01-23-1 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 --- ## #71843 — Pierre Joye — 2014-01-31T11:15:40+00:00 URL: https://externals.io/message/71649#71843 · In reply to: #71811 > Hi! > > > […] > > Yeah, I looked at that patch and also at the diff between what > replace.php produces and what is the end result, and it kind of worries > me. There is a massive misunderstanding about the options provided in the votes. If the option #2 and #3 are accepted, only, I repeat, only the declarations of the variables used by zpp have to be changed, nothing else, no #ifdef, etc. Obviously codes relying on the size of the variable storing the length of a char/buffer have to be changed or adapted as well, same goes for 64bit code on non linux platforms, or platforms having long not being 8 bytes on 64bit builds. The only other parts is the array index and stat operation, but these are not related to the option #2 and #3 and have to be done anyway already if one cares about LFS. > Especially the part when you have to manually update all the types > and how easy it is to miss one. > Not sure, if this is solved > automatically then I might be overreacting but right now it looks like > I, for example, have been underestimating the amount of code disruption > this is causing. It can be automated for zpp, it is almost the case already and Anatol is working on this part to fully automate zpp changes (with option #2 and #3). > I think refactoring PHP types and cleaning them up is a > good idea, but it also means I can't recommend 5.6 adoption to anybody > for years after the release, after we're sure extensions that were > disrupted are stable again. And we're not on stellar numbers with 5.5 > adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth > ride unless you mess with opcodes. > > Again, I'm not against the idea of the patch or the implementation, but > looking at how much work it seems to take for ext author, I'd say it may > be a good start for PHP 6 branch. I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the int64 branch, it will be a better example than what we can see in mongodb, which does not use option #2 and #3. It is basically bad as many of us only focus on this constellation and totally ignore these options which were added as a possible very good compromise. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #71844 — Pierre Joye — 2014-01-31T11:18:22+00:00 URL: https://externals.io/message/71649#71844 · In reply to: #71840 > > > > […] > > Yes, in case you didn't know, 5.6 already has a release: > http://www.php.net/archive/2014.php#id2014-01-23-1 Check when the RFC was proposed, when it was initially created, how many mails have been sent to the list to get feedback about how things are done, etc. etc. So excuse me, but I am totally not going any "late" argument, especially as almost everyone voting no did not say a single word in months. In the other hands, other arguments about the amount of changes are very valid and that's why option #2 and #3 have been added, see my last reply to Stas for more details. -- Pierre @pierrejoye | http://www.libgd.org --- ## #71851 — Arvids Godjuks — 2014-01-31T11:30:41+00:00 URL: https://externals.io/message/71649#71851 · In reply to: #71839 2014-01-31 Derick Rethans : > > > > […] > RFC. > > […] > https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master > > […] > > "Several days" for one extension. Imagine that you maintain a dozen. Are > you really expecting that people will like it to have to spend a month > porting all their extensions for such a marginal benefit? And that for a > *minor* release? I ask you, does it really matter if you have to do it for 5.6 or 6.0? You have to do it anyway sooner or later. For once, I feel that if I had a dozen extensions to maintain, I would welcome the ability to spread the workload between adopting 64 bit support in 5.6 and adopting whatever big changes will come with 6.0 (and as that is a major versions - there probably will be _A LOT) of stuff changing). Sometimes fanatically sticking to the rules of development is not the best course of action - you have to make exceptions in some cases and try to adjust the workflow so that you don't end up forcing people to do too much work at once. Otherwise you end up with slow adoption. > > […] > > Seriously, the MongoDB extension isn't that complicated. There are a lot > of methods, but no different from any other database extension. > There are always some extensions with a much bigger work needed to be done than the rest. Database extensions are one of the biggest challenges to convert. > > > […] > > No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I > even support 5.1 for Xdebug. But with this change, the 5.6 compatible > code is drastically different from the 5.2-5.5 ones. > 5.3 is in the EOL phase and is not maintained at this point. It's EOL ends in June. So with 5.6 all you have to maintain is 5.4 to 5.6 . Remember - no more than 3 branches at one time are supported. > > > […] > > Uhm, the current situation works just fine. I wouldn't call this > technical debt. I am also not saying that this branch is not a good > thing—but so would be "consistent function naming" or "case sensitive > function/method names"—and we're not never going to get these either. > Sorry, it's not a technical dept? As a userland developer, I had my moments cursing the PHP developers in general for not properly working PHP in 64 bit environment. True, maybe I'm that not so often case of the PHP developer working with stuff that needs those 64 bit integer (my project does not work under 64 bit windows properly) to do my calculations because 32 bit integer is too small. P.S. I want to mention the general trend in the software development of "fuck 64 bits, it can run in 32 bit mode anyway". And we get what we get - almost a decade of 64 bit processor availability and half the software still doesn't not support it properly. This is just a remark. --- ## #71857 — Derick Rethans — 2014-01-31T11:46:23+00:00 URL: https://externals.io/message/71649#71857 · In reply to: #71851 > 2014-01-31 Derick Rethans : > > > […] > > 5.3 is in the EOL phase and is not maintained at this point. It's EOL > ends in June. So with 5.6 all you have to maintain is 5.4 to 5.6 . > Remember - no more than 3 branches at one time are supported. My commercial customers as well as my current employer disagrees. Whatever "php.net" decides not to support anymore has no impact on the commercial world. There is a lot more custom extensions out there than you probably expect. > > […] > > Sorry, it's not a technical dept? As a userland developer, I had my > moments cursing the PHP developers in general for not properly working > PHP in 64 bit environment. PHP works just fine a proper 64-bit environment. 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 --- ## #71866 — johannes@schlueters.de — 2014-01-31T12:36:32+00:00 URL: https://externals.io/message/71649#71866 · In reply to: #71649 > https://wiki.php.net/rfc/size_t_and_int64 It is my understanding that part of the reason for the release workflow RFC was that if patches miss the mark they don't have to wait for long till the next release comes. In this case here we have 5.6.0alpaha1 out. Adding a major API change touching each and every file can't be added to 5.6 anymore. Also the release process RFC says x.y.z to x.y+1.z [...] ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowed This rule contains many things that "can" and "should" and thus is open to interprettation. In my interpretation this rule is meant to allow small changes, affecting only few extensions and where it would be stupid to defer the. I think adding this patch to 5.x therefore would be quite some bending of that rule and that combined with the fact that it is late makes me believe that proposing this for 5.6 is illegal. johannes --- ## #71867 — Ulf Wendel — 2014-01-31T12:41:58+00:00 URL: https://externals.io/message/71649#71867 · In reply to: #71866 Am 31.01.2014 13:36, schrieb Johannes Schlüter: > I think adding this patch to 5.x therefore would be quite some bending > of that rule and that combined with the fact that it is late makes me > believe that proposing this for 5.6 is illegal. Are you saying the RFC is 'illegal' ? If the subject proposed is not allowed, it would make litte sense collecting votes. Ulf --- ## #71868 — Pierre Joye — 2014-01-31T12:51:31+00:00 URL: https://externals.io/message/71649#71868 · In reply to: #71866 On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter wrote: > > > […] > > It is my understanding that part of the reason for the release workflow > RFC was that if patches miss the mark they don't have to wait for long > till the next release comes. > > In this case here we have 5.6.0alpaha1 out. Adding a major API change > touching each and every file can't be added to 5.6 anymore. > > > Also the release process RFC says > > x.y.z to x.y+1.z > [...] > ABI and API can be broken (internals), src compatibility > should > be kept if possible, while breakages are allowed > > This rule contains many things that "can" and "should" and thus is open > to interprettation. No, it is open to common sense and give us the opportunity to break ABI if we like to in x.y+1. We did that in 5.4 and 5.5. > In my interpretation this rule is meant to allow > small changes, affecting only few extensions and where it would be > stupid to defer the. To defer the ...? And that's your interpretation, which is your good right. However the release RFC allows us to introduce ABI breakages if desired and accepted. > > I think adding this patch to 5.x therefore would be quite some bending > of that rule and that combined with the fact that it is late makes me > believe that proposing this for 5.6 is illegal. At least you did not loose your sense of humor. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #71869 — Andrey Hristov — 2014-01-31T12:54:15+00:00 URL: https://externals.io/message/71649#71869 · In reply to: #71851 > 2014-01-31 Derick Rethans : > > > […] > > > I ask you, does it really matter if you have to do it for 5.6 or 6.0? You > have to do it anyway sooner or later. For once, I feel that if I had a > dozen extensions to maintain, I would welcome the ability to spread the > workload between adopting 64 bit support in 5.6 and adopting whatever big > changes will come with 6.0 (and as that is a major versions - there > probably will be _A LOT) of stuff changing). > Sometimes fanatically sticking to the rules of development is not the best > course of action - you have to make exceptions in some cases and try to > adjust the workflow so that you don't end up forcing people to do too much > work at once. Otherwise you end up with slow adoption. breaking API big time twice is better than breaking it once? > > > […] > > There are always some extensions with a much bigger work needed to be done > than the rest. Database extensions are one of the biggest challenges to > convert. > > > > […] > > 5.3 is in the EOL phase and is not maintained at this point. It's EOL ends > in June. So with 5.6 all you have to maintain is 5.4 to 5.6 . Remember - no > more than 3 branches at one time are supported. heh, and you think that after this date nobody will use 5.3 and ext devs will just say - "uprgade or don't use my functionality". Let's see. Mongo tries to get more customers, which means that 5.3 will be important for them, even after EOL, because 5.3 has already worked in the environment of the customer and the single change is just Mongo added. > > […] > > Sorry, it's not a technical dept? As a userland developer, I had my moments > cursing the PHP developers in general for not properly working PHP in 64 > bit environment. True, maybe I'm that not so often case of the PHP > developer working with stuff that needs those 64 bit integer (my project > does not work under 64 bit windows properly) to do my calculations because > 32 bit integer is too small. maybe because Windows is broken in that regard and the fix that comes is about fixing Windows but invoicing all OSes. > > P.S. I want to mention the general trend in the software development of > "fuck 64 bits, it can run in 32 bit mode anyway". And we get what we get - > almost a decade of 64 bit processor availability and half the software > still doesn't not support it properly. This is just a remark. > Because only a few applications need real 64 bit. Databases are one example. Andrey --- Next page: https://externals.io/message/71649.md?page=2