On 24/12/11 18:22, Anthony Ferrara wrote:
> It's really simple, and would likely be optimized away by the compiler
> anyway, but I figured it was worth cleaning up...
Yep, it's straightforward.
I'm not sure if it makes a difference or not.
IS_DOUBLE is between IS_LONG and IS_BOOL so the compiler c
On 24/12/11 15:55, Lester Caine wrote:
> I'm with Derek ... having commits that are just WS corrections can be
> irritating when tracking changes ... but it would most definitely
> better to get them fixed before moving to git which would lump mass
> commits like that together in a change set and m
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
> uncon
Hi!
It's not only bad for merges, also confusing with blame/annotate while
identifying the reason for bug.
As soon as we move to git, IIRC git has ability to separate ws-changes
from non-ws ones and do diffs/history while ignoring ws. I didn't figure
out if you can do non-ws merge (I suspect
Hey all,
I found a superfluous if statement while investigating another issue.
I submitted a bug to clean it up and attached a patch:
https://bugs.php.net/bug.php?id=60596
It's on line 56 of /ext/spl/spl_engine.c :
http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_engine.c#56
It's really simple, an
hi Ilia,
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 wrote:
> In most instances integers and floats can be u
In most instances integers and floats can be used interchangeably,
which is why the patch was written in the way that it was. In the few
rare cases (int) cast takes care of the trick, there is a substantial
benefit for timings etc... to have higher precision timestamp
available at no additional cos
On Sat, Dec 24, 2011 at 3:47 PM, André Rømcke wrote:
> Yes, this is the one from Zeta Components MvcTools.
> In eZ Publish it was db based session gc using REQUEST_TIME
> and compatibility for potential extensions that might have used this
> variable via eZ Publish
> api: https://github.com/ezsys
You missed the @ before the number ;)
On Sat, Dec 24, 2011 at 4:00 PM, Pierre Joye wrote:
> On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans wrote:
>
>> new DateTime("@{$_SERVER['REQUEST_TIME']}"); f.e.
>
> Not following you here, how does it work better in 5.3.x? It is a
> float but datetime fa
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans wrote:
> new DateTime("@{$_SERVER['REQUEST_TIME']}"); f.e.
Not following you here, how does it work better in 5.3.x? It is a
float but datetime fails just like before.
php536nts>php -n -r "var_dump($_SERVER['REQUEST_TIME']);new
Datetime($_SERVER[
Pierre Joye wrote:
Laruence refers to the PHP C source code and removing trailing white
>> spaces is a good thing as it is part of our CS.
>>
>> Go ahead Laruence:)
>
> Please don't. Changing whitespace en-masse makes it a royal pain to do
> merges later. Please just fix them when you change
On Sat, Dec 24, 2011 at 12:55 PM, Derick Rethans wrote:
> On Sat, 24 Dec 2011, Pierre Joye wrote:
>
> > hm, I should read better...
> >
> > "The REQUEST_TIME value inside server now returns a floating point
> number"
> >
> > How does it break BC except if one is doing a strong type test? which
>
Hi:
It is necessary that highlight the tail ws in view svn. that can help
us avoid adding more tail ws ..
:)
thanks
2011/12/24 Pierre Joye :
> 2011/12/24 Johannes Schlüter :
>
>> It's not only bad for merges, also confusing with blame/annotate while
>> identifying the reason for bug.
>
> Huh, s
2011/12/24 Johannes Schlüter :
> It's not only bad for merges, also confusing with blame/annotate while
> identifying the reason for bug.
Huh, since when do we commit or recommend to commit WS changes with
actual changes?
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Sat, Dec 24, 2011 at 12:56 PM, Derick Rethans wrote:
> On Sat, 24 Dec 2011, Pierre Joye wrote:
>
>> Laruence refers to the PHP C source code and removing trailing white
>> spaces is a good thing as it is part of our CS.
>>
>> Go ahead Laruence :)
>
> Please don't. Changing whitespace en-masse m
2011/12/24 Johannes Schlüter :
> On Sat, 2011-12-24 at 11:56 +, Derick Rethans wrote:
>> On Sat, 24 Dec 2011, Pierre Joye wrote:
>>
>> > Laruence refers to the PHP C source code and removing trailing white
>> > spaces is a good thing as it is part of our CS.
>> >
>> > Go ahead Laruence :)
>>
>>
On Sat, 2011-12-24 at 11:56 +, Derick Rethans wrote:
> On Sat, 24 Dec 2011, Pierre Joye wrote:
>
> > Laruence refers to the PHP C source code and removing trailing white
> > spaces is a good thing as it is part of our CS.
> >
> > Go ahead Laruence :)
>
> Please don't. Changing whitespace en-
On Sat, 24 Dec 2011, Pierre Joye wrote:
> Laruence refers to the PHP C source code and removing trailing white
> spaces is a good thing as it is part of our CS.
>
> Go ahead Laruence :)
Please don't. Changing whitespace en-masse makes it a royal pain to do
merges later. Please just fix them whe
On Sat, 24 Dec 2011, Pierre Joye wrote:
> hm, I should read better...
>
> "The REQUEST_TIME value inside server now returns a floating point number"
>
> How does it break BC except if one is doing a strong type test? which
> makes very little sense in this case.
>
> While a fix is easy, (int) c
Oh, shame on my, I was thinking about PHP code. Even so, this is
coding standards for PHP C code. Have we this? This can be a good one.
On Sat, Dec 24, 2011 at 9:11 AM, Pierre Joye wrote:
> hi!
>
> Laruence refers to the PHP C source code and removing trailing white
> spaces is a good thing as it
hi!
Laruence refers to the PHP C source code and removing trailing white
spaces is a good thing as it is part of our CS.
Go ahead Laruence :)
On Sat, Dec 24, 2011 at 12:09 PM, Rafael Kassner wrote:
> AFAIK, PHP files are transformed in bytecode before the execution, so
> white spaces will not i
AFAIK, PHP files are transformed in bytecode before the execution, so
white spaces will not interfere in nothing except more time to
transfer the file over SFTP.
It's pretty good to implement on our IDEs (and a lot of them is doing
it), once trailing white spaces are annoying while we are developi
Haven't tried myself yet but could it be André is refering to a change
from Ilia from 11/2010?
http://git.php.net/?p=php-src.git;a=commit;h=435783f703bc762aad0f9269234bd383d4a55230
Kind regards,
Stefan
On 12/24/2011 12:01 PM, Pierre Joye wrote:
> hi,
>
> I don't remember a change about it an
hm, I should read better...
"The REQUEST_TIME value inside server now returns a floating point number"
How does it break BC except if one is doing a strong type test? which
makes very little sense in this case.
While a fix is easy, (int) casting and works with all previous
versions, I would like
hi,
I don't remember a change about it and did not check the log yet.
Would you mind to write here how it is broken please? It could help
the discussions :)
But yes, if it has changed in an incompatible way, I'd to go with a
revert as well.
Cheers,
On Sat, Dec 24, 2011 at 11:13 AM, André Rømck
Hi,
a bit late to the party maybe, but why was REQUEST_TIME broken in 5.4
instead of adding a new parameter? (like REQUEST_MICROTIME)
Is the Release Process not followed yet?
- x.y.z to x.y+1.z
- (...)
- Backward compatibility must be kept
( https://wiki.php.net/rfc/releaseproc
On Sat, Dec 24, 2011 at 8:40 AM, Will Fitch wrote:
> In the interest of providing options for an ability to mark a method as
> returning null, I have added a new patch here:
> http://www.willfitch.com/php/nullable.patch
>
> This includes a new token "T_NULLABLE". Here are a few examples:
>
> //
27 matches
Mail list logo