Recently, as part of school course on optimization, I have identified a
potential optimization or feature for PHP. After looking through the
array.c file(located in etc/standard in the PHP source code), I noticed
that both the in_array and array_search are using the linear search C
function php_sea
On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki wrote:
> Hi Pierre,
>
> On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye wrote:
>>
>> Same effects but totally unrelated topics. All functions dealing with
>> large external numbers had the same issues, since ever. It has nothing
>> to do with STH.
>
>
>
Hi Pierre,
On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye wrote:
> Same effects but totally unrelated topics. All functions dealing with
> large external numbers had the same issues, since ever. It has nothing
> to do with STH.
>
Yes, it is.
Developers make casting mistakes like this even when t
On Mon, Mar 30, 2015 at 8:25 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Mon, Mar 30, 2015 at 9:07 AM, Yasuo Ohgaki wrote:
>
>> Hi Jakub,
>>
>> On Mon, Mar 30, 2015 at 4:33 AM, Jakub Zelenka wrote:
>>
>>> I would like to add a new option to JSON for dealing with large floats.
>>> The
>>> use case i
Hi all,
On Mon, Mar 30, 2015 at 9:07 AM, Yasuo Ohgaki wrote:
> Hi Jakub,
>
> On Mon, Mar 30, 2015 at 4:33 AM, Jakub Zelenka wrote:
>
>> I would like to add a new option to JSON for dealing with large floats.
>> The
>> use case is mainly for decoder but can be used for encoder as well.
>>
>> JSO
Hi Benoit,
On Sun, Mar 29, 2015 at 2:49 AM, Benoit Schildknecht
wrote:
> Why hasn't it closed ? It's way past the 25th.
Vote was closed before the end date. IIRC.
It's "withdrawn" status, I suppose.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Jakub,
On Mon, Mar 30, 2015 at 4:33 AM, Jakub Zelenka wrote:
> I would like to add a new option to JSON for dealing with large floats. The
> use case is mainly for decoder but can be used for encoder as well.
>
> JSON_FLOAT_AS_STRING
> decode: all float values will be decoded as string
> - It
This was approved by a vote of 32 - 1.
Dmitry said that he would like to review and possibly polish the patch
before it is committed.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey.
I am running my PHP app through a NodeJS server using a FastCGI bridge. Today,
I was about to implement an image uploader on my site - only to realize that
file uploads were not possible.
So I generated a few files and tested how big the files must be for the upload
to fail. I got surpris
Hi,
I would like to add a new option to JSON for dealing with large floats. The
use case is mainly for decoder but can be used for encoder as well.
JSON_FLOAT_AS_STRING
decode: all float values will be decoded as string
- It's often an issue for very large float values with many fractional
digits
> On 29 Mar 2015, at 17:56, Dan Ackroyd wrote:
>
> On 29 March 2015 at 12:28, Gints Murans wrote:
>
>> What happened to this RFC? This is a really great idea for php.
>
> The 'Skip Params' RFC (https://wiki.php.net/rfc/skipparams) went to
> vote and was declined.
"Named params" sounds a lot b
On 29 March 2015 at 12:28, Gints Murans wrote:
> What happened to this RFC? This is a really great idea for php.
The 'Skip Params' RFC (https://wiki.php.net/rfc/skipparams) went to
vote and was declined.
The 'named params' RFC (https://wiki.php.net/rfc/named_params) author
has been working on st
Hi all,
Voting has now closed on this RFC. The feature has been accepted for PHP 7
with votes of 41 - 0.
Thanks to all who participated in the discussion and gave feedback.
Regards,
Leigh.
Hi,
What happened to this RFC? This is a really great idea for php.
For example this function:
function getIdByTitle($title, $insert = false) {
// find record
// If no record find and $insert === true, insert new record and return
the id
// Return false
}
Reading over s
Le 16/03/2015 07:44, Sara Golemon a écrit :
The voting period for the "Even More" type hints reservation RFC is now open.
Hi,
Discussing this RFC with other people at AFUP, we are +1, for all five
proposed types (well, even if not really "types" today).
Like for the "reserve more types" RFC,
Le 22/03/2015 23:28, Levi Morrison a écrit :
When opening the vote I did not decide when the vote would close.
Unless I hear from someone specifically requesting a longer period, I
will close this RFC on Friday, March 27th sometime in the evening
(UTC-7).
Hi,
It seems I'm a bit late (I didn't
Le 15/03/2015 20:31, Niklas Keller a écrit :
I just opened the vote for the in operator
Hi,
Discussing this RFC with other people at AFUP, it seems the majority of
us ended up on the +1 side.
The idea of a unified syntax to find whether or not something is *in*
something else seems to be in
17 matches
Mail list logo
