hi,
On Sat, Jan 3, 2015 at 5:36 PM, François Laupretre wrote:
> Hi,
>
> I just wrote this RFC to propose a clean way for opcode caches to decide if
> a given URI is cacheable or not :
>
> https://wiki.php.net/rfc/streams-is-cacheable
>
> Please comment.
It looks like a good addtion, thanks :) I
+1 for this PR.
On 4 January 2015 at 09:36, François Laupretre wrote:
> Hi,
>
> I just wrote this RFC to propose a clean way for opcode caches to decide if
> a given URI is cacheable or not :
>
> https://wiki.php.net/rfc/streams-is-cacheable
>
> Please comment.
>
> Regards
>
> François
>
>
>
> -
On Jan 4, 2015 2:56 AM, "Nikita Popov" wrote:
>
> Hi internals!
>
> I'd like to propose removing support for hexadecimal strings in the
> is_numeric_string() function, in order to achieve consistency with
ordinary
> integer and float casts:
>
> https://wiki.php.net/rfc/remove_hex_support_in_nu
Hi,
On Jan 4, 2015 3:10 AM, "Andrea Faulds" wrote:
>
> Hi Sebastian,
>
> > On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen
wrote:
> >>
> >> Yeah, I don’t like this behaviour much. I want to avoid inconsistency
with the behaviour of extension functions (i.e. zend_parse_parameters)
where possible,
> On 4 Jan 2015, at 12:34 pm, Thomas Hruska wrote:
>
>> On 1/3/2015 4:56 PM, David Muir wrote:
>> Shouldn't this be directed to the webmaster mailing list?
>> php-webmas...@lists.php.net
>
> See below. They said that they don't have access to that server. :)
>
>
Ah, missed that part. So w
Hi,
I just wrote this RFC to propose a clean way for opcode caches to decide if
a given URI is cacheable or not :
https://wiki.php.net/rfc/streams-is-cacheable
Please comment.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/
On 1/3/2015 4:56 PM, David Muir wrote:
Shouldn't this be directed to the webmaster mailing list?
php-webmas...@lists.php.net
See below. They said that they don't have access to that server. :)
On 4 Jan 2015, at 4:45 am, Thomas Hruska wrote:
On 12/28/2014 4:47 PM, Thomas Hruska wrote:
On Sat, Jan 3, 2015 at 3:42 PM, Nikita Popov wrote:
> Or maybe be more explicit and use "cstr" for C strings. (For symmetry the
> zend_string type could become zstr.)
>
I personally prefer cstr/zstr for explicitness, but agree that the
main focus should be consistency.
-Sara
And yes, the fact th
Shouldn't this be directed to the webmaster mailing list?
php-webmas...@lists.php.net
Sent from my iPhone
> On 4 Jan 2015, at 4:45 am, Thomas Hruska wrote:
>
>> On 12/28/2014 4:47 PM, Thomas Hruska wrote:
>>> On 12/7/2014 10:52 PM, Thomas Hruska wrote:
On 11/29/2014 6:27 AM, Thomas Hruska
Hey Nikita,
> On 3 Jan 2015, at 23:42, Nikita Popov wrote:
>
> Basically if you have two APIs, one using str, the other using string, you
> can't tell which one is for C strings and which one is for zend_strings. It
> could be either way.
>
> It would be nice to have a convention for this and s
Hi internals!
PHP 7 uses two different string types. One is the ordinary C string char*,
the other is a custom zend_string* structure, which additionally embeds
length and GC info.
We currently have a bunch of APIs that accept either C strings or
zend_strings, but the naming is pretty much random
Hi!
> I'd like to propose removing support for hexadecimal strings in the
> is_numeric_string() function, in order to achieve consistency with ordinary
> integer and float casts:
>
> https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
>
> This change drops a WTF in our conversion
On Sat, Jan 3, 2015 at 11:55 AM, Nikita Popov wrote:
> I'd like to propose removing support for hexadecimal strings in the
> is_numeric_string() function, in order to achieve consistency with ordinary
> integer and float casts:
>
> https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
Hi Thomas,
> On 3 Jan 2015, at 20:00, Thomas Bley wrote:
>
> Here is what I run on my ubuntu 14.04 for compiling & testing:
>
> apt-get install build-essential re2c bison
> git clone -b master https://github.com/php/php-src.git
> cd php-src
> curl https://github.com/php/php-src/pull/972.patch |
Hi Sebastian,
> On 3 Jan 2015, at 19:46, Sebastian B.-Hagensen wrote:
>>
>> Yeah, I don’t like this behaviour much. I want to avoid inconsistency with
>> the behaviour of extension functions (i.e. zend_parse_parameters) where
>> possible, though. Since this has come up so much, I should probab
Here is what I run on my ubuntu 14.04 for compiling & testing:
apt-get install build-essential re2c bison
git clone -b master https://github.com/php/php-src.git
cd php-src
curl https://github.com/php/php-src/pull/972.patch | git am
./buildconf
./configure
make
sapi/cli/php /tmp/test.php
test.php
Hi internals!
I'd like to propose removing support for hexadecimal strings in the
is_numeric_string() function, in order to achieve consistency with ordinary
integer and float casts:
https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
This change drops a WTF in our conversion sema
>> - on-numeric strings not accepted. Numeric strings with trailing
>> characters are accepted, but produce a notice.
>>
>> I would rather not allow fancy conversions here. Any trailing non
>> white spaces characters should not be allowed. I know it is not what
>> PHP does now in some cases but thi
Hey Pierre,
> Thanks, great work and persistent effort!
Thank you.
> As I am also slightly in favor of a strict way, this RFC is a good compromise.
>
> Some comments:
>
> - on-numeric strings not accepted. Numeric strings with trailing
> characters are accepted, but produce a notice.
>
> I wo
On 12/28/2014 4:47 PM, Thomas Hruska wrote:
On 12/7/2014 10:52 PM, Thomas Hruska wrote:
On 11/29/2014 6:27 AM, Thomas Hruska wrote:
On 11/15/2014 12:13 AM, Pierre Joye wrote:
Good point. They will remain in the archives part. We kept them after
eol
just in case there was a last min critical up
On 03.01.2015 05:50, Pierre Joye wrote:
> I am also not a fan of errors, exception, at least for methods, make
> much more sense. I know it is relatively easy to handle errors as
> exception but still, let do it right now.
I second this; this could be an excellent opportunity into that
direction f
21 matches
Mail list logo
