On Mon, May 30, 2016 at 7:18 PM, Stanislav Malyshev wrote:
>> In fact, the idea of stripping content from a script file isn't
>> without precedent. Shebang lines are routinely removed from
>> cli/cgi/fpm, and if you want to properly output it, you need to do so
>
> True, because in the context of
Hi!
> In fact, the idea of stripping content from a script file isn't
> without precedent. Shebang lines are routinely removed from
> cli/cgi/fpm, and if you want to properly output it, you need to do so
True, because in the context of CLI we know what is expected - a CLI
script which can start
>
> Ported to https://github.com/Ocramius/array_change_keys-benchmark, thanks!
>
I've updated the RFC's benchmarks based on your tool. They confirm that
array_change_keys is faster than array_combine but slower than foreach (in
most cases). Thanks for helping with this!
> No, but I really don'
On 31/05/16 02:33, Sammy Kaye Powers wrote:
BOM's should not be treated as characters and should not be sent to
the output. Is there any reason this should be considered the expected
behavior? If not, I'd like to create an RFC to change it. :)
What about
«Hello Foo!
Today is » ?
If there's a B
On Mon, May 30, 2016 at 5:40 PM, Stanislav Malyshev wrote:
>> BOM's should not be treated as characters and should not be sent to
>> the output. Is there any reason this should be considered the expected
>> behavior?
>
> The reason would be PHP does not know where surrounding output ends and
> the
Hi!
> BOM's should not be treated as characters and should not be sent to
> the output. Is there any reason this should be considered the expected
> behavior?
The reason would be PHP does not know where surrounding output ends and
the code starts, beyond http://www.php.net/unsub.php
Hey internals!
In a recent discussion on PHP Roundtable, we talked about the byte
order mark in php files. If you create a php file with the following:
PHP Warning: Cannot modify header information - headers already sent by
> (output started at %s:1) in %s on line %d
But it doesn't seem to re
On 30 May 2016 at 03:40, Colin O'Dell wrote:
> Marco,
>
>
>> 1. could you also provide the code for the benchmarks? I'd gladly
>> measure them with an accurate tool
>>
>
> Yeah that would be great! Here's the benchmark I was using:
> https://gist.github.com/colinodell/872c1f0c92351af687347c0c8b
I benchmarked this more carefully at
https://github.com/Ocramius/array_change_keys-benchmark - the results are
indeed not matching what is represented in the RFC.
Specifically, `array_change_keys` has performance that is comparable to
`array_combine` + `array_map`, and looping is still faster by a
On Mon, May 30, 2016 at 7:46 PM, Fleshgrinder wrote:
> On 5/30/2016 8:28 PM, Nikita Popov wrote:
> > This proposal adds a new json.precision setting. Why? I've been told that
> > this is more flexible, which is fair enough, but imho we should have very
> > strong reasons for introducing new ini s
On Mon, May 30, 2016 at 7:28 PM, Nikita Popov wrote:
> On Mon, May 30, 2016 at 6:34 PM, Jakub Zelenka wrote:
>
>> On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki wrote:
>>
>> > Hi all,
>> >
>> > IEEE 754 double cannot express exact float values. That said,
>> > float values expressed by json/seria
On Mon, May 30, 2016 at 3:40 AM, Colin O'Dell wrote:
> Marco,
>
>
> > 1. could you also provide the code for the benchmarks? I'd gladly
> measure
> > them with an accurate tool
> >
>
> Yeah that would be great! Here's the benchmark I was using:
> https://gist.github.com/colinodell/872c1f0c92351
On 5/30/2016 8:28 PM, Nikita Popov wrote:
> This proposal adds a new json.precision setting. Why? I've been told that
> this is more flexible, which is fair enough, but imho we should have very
> strong reasons for introducing new ini settings. Reasons that go beyond "it
> might be useful to someon
On Mon, May 30, 2016 at 6:34 PM, Jakub Zelenka wrote:
> On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki wrote:
>
> > Hi all,
> >
> > IEEE 754 double cannot express exact float values. That said,
> > float values expressed by json/serialize/var_export/echo/print
> > are not precise enough in many ca
On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> IEEE 754 double cannot express exact float values. That said,
> float values expressed by json/serialize/var_export/echo/print
> are not precise enough in many cases.
>
> Issues:
> - json_encode() uses EG(precision)=14 that trunca
Results for project PHP master, build date 2016-05-30 06:28:09+03:00
commit: 2a0261d
previous commit:42be298
revision date: 2016-05-29 06:03:33+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
16 matches
Mail list logo
