Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
Hi! On one side there's a clear BC break which, according to the related RFC, is to be considered as a blocker, on the other one, a strong and valid argument regarding spreading additional server variables. I'm not sure being late in the release process is truely a valid argument for accepting a BC break. If we are to fix it, I don't think it's too late. One of the purposes of the RC process is to find out stuff like this - i.e. BC breaks - and fix them before the release. I do not see a big risk in adding new SERVER variable - I don't believe there's any code that relies on certain variable *not* existing, and since the code to produce it already exists and considered stable, there's very little risk in just renaming it. Can't we make some compromise here like making all date/time classes/functions work uniformly with ints and floats? However for this is probably way too late, since it's not a BC fix, it's completely new and untested functionality. So if somebody wants to make a patch that makes REQUEST_TIME be back as it was and make REQUEST_TIME_MSEC (or something like this) have msec precision - I think it would be fine. Doing anything to all date/time classes/functions is definitely out of the question, IMO. For 5.4.1, it may be considered if done in a clean manner, but not for 5.4.0. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: ionixjunior
Being inside all the news yet to come in future versions of PHP, and also participate in polls. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference
Hi! Hi: I have reset the vote, only vote for trunk now. https://wiki.php.net/rfc/constdereference What happens in your patch if something like ['foo', 'bar'][1] is used in write context? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Mon, 26 Dec 2011, Patrick ALLAERT wrote: 2011/12/24 Pierre Joye pierre@gmail.com: Right but there is a clear BC break here. And yes I really don't like how datetime deals with that but it is how it is, and it is certainly the only case where it fails (or almost). On Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. On one side there's a clear BC break which, according to the related RFC, is to be considered as a blocker, An RFC? Which one? on the other one, a strong and valid argument regarding spreading additional server variables. I'm not sure being late in the release process is truely a valid argument for accepting a BC break. Can't we make some compromise here like making all date/time classes/functions work uniformly with ints and floats? It's parsing a *string*, not an int or float. Changing anything with how the parser works is definitely going to be a clear BC break. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2011/12/27 Ilia Alshanetsky i...@ilia.ws: I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. As mentioned earlier, I don't like this option very much but at least it solves the BC problem. Do you have any other proposal to share? Opposing to that without proposing a solution kinda looks like I don't bother if it breaks BC. -- Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference
On Tue, Dec 27, 2011 at 2:42 PM, Dmitri Snytkine dsnytk...@ultralogistics.com wrote: Odd how substring can be used as index of string. oh, I see where the confusion comes from. the reason why foobar[foo] returns 'f' isn't that foo is a substring of foobar, but that foo will be casted to int, which will result in foobar[0], which in turn will result in 'f' and foobar[3 apples] would return 'b' for example. it's an unexpected behavior for many people, but it is how it works and we even documented this. as I mentioned in my previous mail, we will try to make this a little bit more noisy, as this can lead to hard to spot bugs. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2011/12/27 Pierre Joye pierre@gmail.com: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) :) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? a)++ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: bug 52062
On Sun, 25 Dec 2011, Stas Malyshev wrote: I see that test for bug 52062 (marked as fixed by this commit: http://svn.php.net/viewvc/?view=revisionamp;revision=320481) now fails on my 32-bit system. Looking at the patch and the test, it can not actually succeed, as the test expects this: int(1000) which is not possible on 32-bit system, and the code actually compares the result to LONG_MAX which is 32-bit and returns false when it's bigger that that. So I'd like to know what was the intent there: 1. Return false on 32-bit and the test should be fixed to account for 32-bit and 64-bit? 2. Return float on 32-bit? 3. Do something else? Please advise. There are several issues here: 1. The test was wrong, the result for var_dump($d-getTimestamp()); should indeed have been bool: false; I've a patch for this. 2. DateInterval::format() didn't handle large ints succesfully; I have a patch for this too. 3. $d-setTimestamp(1000) is not ever going to work as zend_parse_parameters simply gives me long: 1215752192. This I find really strange actually. Any clue? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
Ilia Alshanetsky wrote: I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. A proper explanation of why you take that attitude would be helpful. Personally I expect REQUEST_TIME to be in the same resolution as the http format time stamps which does not include milliseconds (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1). Personally DATE is a floating point value with the fractional part being the fraction of the day. So adding another variation to cope with does not make any sense. So adding a non-standard environment variable for those who want it rather than screwing up the existing one is the logical approach? On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethansder...@php.net wrote: On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethansder...@php.net wrote: Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? I'd vote for a (REQUEST_TIME_FLOAT), as MSEC is not what it really does. Depending on the time and precision it might not show miliseconds f.e. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference
On Tue, Dec 27, 2011 at 4:38 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Hi: I have reset the vote, only vote for trunk now. https://wiki.php.net/rfc/constdereference What happens in your patch if something like ['foo', 'bar'][1] is used in write context? this patch will not allow that, in write context lead to syntax error. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference
On Tue, Dec 27, 2011 at 2:15 PM, Dmitri Snytkine dsnytk...@ultralogistics.com wrote: No sure who can and cannot vote, I don't see any way for me to vote. https://wiki.php.net/rfc/voting currently the following two groups can vote: - people having php.net svn account - people having a wiki account and manually granted with the voters group membership My opinion that it’s a good idea to have array and string dereference. One feature however, looks odd, like it does not belong here: echo foobar[foo][0] // output f Does it look odd to anyone else? I mean, this sort of thing can be added but it just looks like a separate feature alltogether. which part seems odd to you? this rfc and the proposed patch doesn't introduce any new behavior, just allows using foobar everywhere where you could use $foobar = foobar I guess you found it odd that $foobar = foobar; echo $foobar[foo]; prints 'f', but that's not a new feature, this is how php works currently. we had a discussion about that recently, and AFAIK in the latest 5.4, a warning will be triggered if you try to reference a string offset using a string index. the scalar referencing proposed here should (and AFAIK it does) behave exactly the same as it would work if a variable with the same value would be used. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Scalars will not be supported as type hints. There was talk of a scalar token added for validation in that category, but it does NOT need to be supported for return type hinting to be included. Return type hints are following the same logic as parameter type hints and should be considered in that category. On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote: I think annotations is a completely different topic to be discussed separately. First the type hinting for variables and return values has to be supported by the language, including hinting for primitive types. If and when this is done, then, if annotations are supported natively, maybe these 2 can be combined. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com] Sent: Tuesday, December 27, 2011 11:12 AM To: PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time. To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch will.fi...@gmail.com The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return Type Hinting for Methods RFC
Also, the RFC will be changing tonight/tomorrow'ish to take procedures (functions) into account as well. I know there are many who want to address the additional types to hint (e.g. scalar keyword), but I would like to focus discussion of the RFC to its current state - which is to match the state of parameter type hints. On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote: I think annotations is a completely different topic to be discussed separately. First the type hinting for variables and return values has to be supported by the language, including hinting for primitive types. If and when this is done, then, if annotations are supported natively, maybe these 2 can be combined. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com] Sent: Tuesday, December 27, 2011 11:12 AM To: PHP Developers Mailing List Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time. To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch will.fi...@gmail.com The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
The change is inside 5.4 version which adjust breaks BC. --- Ilia On Dec 27, 2011 10:15 AM, Patrick ALLAERT patrickalla...@php.net wrote: 2011/12/27 Ilia Alshanetsky i...@ilia.ws: I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. As mentioned earlier, I don't like this option very much but at least it solves the BC problem. Do you have any other proposal to share? Opposing to that without proposing a solution kinda looks like I don't bother if it breaks BC. -- Patrick
Re: [PHP-DEV] Return Type Hinting for Methods RFC
I'm sorry but even though I liked that RFC, I'd like to ask about type hinting through annotations. Has anyone considered that? I think that it would be nice because it also docs the functions at the same time. To be honest I don't know even if that's possible. So, it's just a thought. 2011/12/24 Will Fitch will.fi...@gmail.com The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: On 12/23/11 13:34, Will Fitch will.fi...@gmail.com wrote: There's still the matter of whether allowing null to be returned, regardless of the situation, or using another token to identify that it could return null. I'd like to know what others think. I see Stas' argument that you'll still have to check, but I'm not so sure that is such a bad thing. I see it as a very bad thing, for two reasons: 1) Unconditionally allowing null to be returned takes away an element of control. You can't get away from error handling, but it's nice to be able to handle errors how you want. Having nulls thrown at you at any time means you have to be ready to handle them at any time, rather than handling them off in a separate area where you have taken the time to properly prepare for them. This makes for a lot more redundant code unrelated to the core functionality of the code, and it kills much of the utility of things like fluent interfaces. 2) With type-hinted parameters, the choice has already been made not to allow null values at any time. Rather, the programmer must explicitly allow them in the parameter declaration. Doing the same with return types would provide an important bit of consistency. Regards, Bob -- Robert E. Williams, Jr. Associate Vice President of Software Development Newtek Businesss Services, Inc. -- The Small Business Authority https://www.newtekreferrals.com/rewjr http://www.thesba.com/ Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans der...@php.net wrote: On Mon, 26 Dec 2011, Patrick ALLAERT wrote: 2011/12/24 Pierre Joye pierre@gmail.com: Right but there is a clear BC break here. And yes I really don't like how datetime deals with that but it is how it is, and it is certainly the only case where it fails (or almost). On Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. On one side there's a clear BC break which, according to the related RFC, is to be considered as a blocker, An RFC? Which one? https://wiki.php.net/rfc/releaseprocess Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC]Call for voting about const array/string dereference
Odd how substring can be used as index of string. Dmitri Snytkine Web Developer Ultra Logistics, Inc. Phone: (888) 220-4640 x 2097 Fax: (888) 795-6642 E-Mail: dsnytk...@ultralogistics.com Web: www.ultralogistics.com A Top 100 Logistics I.T. Provider in 2011 -Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Tuesday, December 27, 2011 8:24 AM To: Dmitri Snytkine Cc: Laruence; Pierre Joye; Patrick ALLAERT; Nikita Popov; PHP Internals Subject: Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference On Tue, Dec 27, 2011 at 2:15 PM, Dmitri Snytkine dsnytk...@ultralogistics.com wrote: No sure who can and cannot vote, I don't see any way for me to vote. https://wiki.php.net/rfc/voting currently the following two groups can vote: - people having php.net svn account - people having a wiki account and manually granted with the voters group membership My opinion that it’s a good idea to have array and string dereference. One feature however, looks odd, like it does not belong here: echo foobar[foo][0] // output f Does it look odd to anyone else? I mean, this sort of thing can be added but it just looks like a separate feature alltogether. which part seems odd to you? this rfc and the proposed patch doesn't introduce any new behavior, just allows using foobar everywhere where you could use $foobar = foobar I guess you found it odd that $foobar = foobar; echo $foobar[foo]; prints 'f', but that's not a new feature, this is how php works currently. we had a discussion about that recently, and AFAIK in the latest 5.4, a warning will be triggered if you try to reference a string offset using a string index. the scalar referencing proposed here should (and AFAIK it does) behave exactly the same as it would work if a variable with the same value would be used. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/NEWS branches/PHP_5_4/acinclude.m4 trunk/acinclude.m4
Am 27.12.2011 14:53, schrieb Hannes Magnusson: bjoriTue, 27 Dec 2011 13:53:11 + Revision: http://svn.php.net/viewvc?view=revisionrevision=321435 Log: Looks like we need to explicity add libstdc++ on recent linux' too, like fedora 14 and ubuntu 11 This fixes build failures for ext/intl and several pecl exts Changed paths: U php/php-src/branches/PHP_5_4/NEWS U php/php-src/branches/PHP_5_4/acinclude.m4 U php/php-src/trunk/acinclude.m4 And PHP_5_3 does not need this? -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
I think the REQUEST_TIME semantics of returning float should remain as is. -1 for adding further environment variables. On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethans der...@php.net wrote: On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? I'd vote for a (REQUEST_TIME_FLOAT), as MSEC is not what it really does. Depending on the time and precision it might not show miliseconds f.e. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, 27 Dec 2011, Pierre Joye wrote: On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? I'd vote for a (REQUEST_TIME_FLOAT), as MSEC is not what it really does. Depending on the time and precision it might not show miliseconds f.e. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net wrote: Ah, that one. I got lost between all the commas and thought he meant an RFC for changing REQUEST_TIME from int to float :-) :) Which name should we use? a) REQUEST_TIME_FLOAT b) REQUEST_TIME_MSEC c) other? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
hi Derick, On Tue, Dec 27, 2011 at 11:37 AM, Derick Rethans der...@php.net wrote: On Mon, 26 Dec 2011, Patrick ALLAERT wrote: 2011/12/24 Pierre Joye pierre@gmail.com: Right but there is a clear BC break here. And yes I really don't like how datetime deals with that but it is how it is, and it is certainly the only case where it fails (or almost). On Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky i...@ilia.ws wrote: Introducing additional server variables just makes things inconsistent, especially this late in the release cycle. On one side there's a clear BC break which, according to the related RFC, is to be considered as a blocker, An RFC? Which one? https://wiki.php.net/rfc/releaseprocess Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 52062
On Mon, 26 Dec 2011, Antony Dovgal wrote: On 12/26/2011 12:40 PM, Derick Rethans wrote: I'll have a look when I get back home. Is there anything else you want me to look at? Yes! https://bugs.php.net/bug.php?id=53437 =) I've just had a look at the patch, and it seems to encode things in weird stuff for DatePeriod (packed ints, base64)?!. It also seems to re-implement the DateInterval serialisation and the patch doesn't cleanly apply. Gustavo, could you try find me on IRC? cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
The change is inside 5.4 version which adjust breaks BC.
I don't follow you here Ilia.
As per https://wiki.php.net/rfc/releaseprocess:
* Backward compatibility must be respected with the same major
releases, for example from 5.2 to 5.6.
* Going from x.y.z to x.y+1.z, it is ok to break *binary*
compatibility but Backward compatibility must be kept.
However:
new DateTime(@{$_SERVER['REQUEST_TIME']});
works in 5.3 but not in 5.4.
AFAIK, creating a DateTime object based on the REQUEST_TIME is not an
exotic thing.
For sure, the fix is easy, but that is not the point, it *will*
actually break applications.
Did I miss something?
--
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 52062
Hi On Tue, 27 Dec 2011 13:26:59 +0100, Derick Rethans der...@php.net wrote: On Mon, 26 Dec 2011, Antony Dovgal wrote: On 12/26/2011 12:40 PM, Derick Rethans wrote: I'll have a look when I get back home. Is there anything else you want me to look at? Yes! https://bugs.php.net/bug.php?id=53437 =) I've just had a look at the patch, and it seems to encode things in weird stuff for DatePeriod (packed ints, base64)?!. Not for DatePeriod, for DateInterval. The problem is that the DateInterval object uses 64-bit integers in its structure, and you can't serialize them as normal PHP integers if you want to have no data corruption in architectures with 32-bit longs like Windows. You seemed to have ignored that difficulty when you later implemented DateInterval serialization. My implementation also does state validation on DateInterval::__wakeup. It also seems to re-implement the DateInterval serialisation and the patch doesn't cleanly apply. Well, the patch is against r305891 (HEAD at the time), DateInterval serialization was implemented in r320481. In any case, if you want to use only the DatePeriod part (which provides serialization and properties), it should work independently from the DateInterval portion. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Sat, Dec 24, 2011 at 7:07 AM, Pierre Joye pierre@gmail.com wrote: Right, and that's why I would be in favour of a BC change, maybe by introducing a REQUEST_TIME_FLOAT instead, so people willing to use the float version can still have it while the existing code needs no change. We spotted the same exact thing when doing the first tests of Drupal on PHP 5.4, which lead to the following change (already released in all the affected versions of Drupal): http://drupal.org/node/1209470 Given how most of PHP miserably fails to handle float timestamp, I'm in favor of reverting the change too. Damien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickalla...@php.netwrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
The change is inside 5.4 version which adjust breaks BC.
I don't follow you here Ilia.
As per https://wiki.php.net/rfc/releaseprocess:
* Backward compatibility must be respected with the same major
releases, for example from 5.2 to 5.6.
* Going from x.y.z to x.y+1.z, it is ok to break *binary*
compatibility but Backward compatibility must be kept.
However:
new DateTime(@{$_SERVER['REQUEST_TIME']});
works in 5.3 but not in 5.4.
AFAIK, creating a DateTime object based on the REQUEST_TIME is not an
exotic thing.
For sure, the fix is easy, but that is not the point, it *will*
actually break applications.
Did I miss something?
I think that he is referring to that we already break BC with 5.4 (removing
magic_quotes, register_globals, break/continue
$var, allow_call_time_pass_reference, some deprecated session_ functions,
safe_mode, etc. for a complete list see
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
)
However I tend to agree with you, that this BC break isn't really worth it,
we can see that there are common apps stumbling across this change, and
albeit the new behavior can be useful for many people, they wouldn't really
mind if we add this as a new variable imo.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/NEWS branches/PHP_5_4/acinclude.m4 trunk/acinclude.m4
On Tue, Dec 27, 2011 at 16:48, Sebastian Bergmann sebast...@php.net wrote: Am 27.12.2011 16:36, schrieb Sebastian Bergmann: And PHP_5_3 does not need this? I am asking because I cannot build PHP_5_3 with ext/intl on Fedora 16. Hmh. Do they not ship with PHP5.3? I would have expect them to submit a build failure bug report if it didn't work. Assuming 5.3 works on their buildbot setup, were can we find their patches to see if they solved it differently -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: bug 52062
Hi! 3. $d-setTimestamp(1000) is not ever going to work as zend_parse_parameters simply gives me long: 1215752192. This I find really strange actually. Any clue? That's probably float to long conversion, since 1000 is float on 32-bit. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
