Hi Andrey,
On Wed, Mar 23, 2016 at 5:03 AM, Andrey Andreev wrote:
>
> On Tue, Mar 22, 2016 at 9:52 PM, Pascal MARTIN, AFUP <
> mail...@pascal-martin.fr> wrote:
>
>> Le 09/03/2016 10:14, Yasuo Ohgaki a écrit :
>>
>>> Vote starts 2016-03-09-09:00(UTC) and ends 2016-03-23-09:00(UTC)
>>> https://wiki
Hi Yasuo,
- Original Message -
From: "Yasuo Ohgaki"
Sent: Tuesday, March 22, 2016
Hi all,
On Fri, Mar 18, 2016 at 9:30 PM, wrote:
---
benchmark relative change since
Hi Dmitry,
- Original Message -
From: "Dmitry Stogov"
Sent: Tuesday, March 22, 2016
Commit:d8b75b0807a5d94bd7b6b175d56aba8bc5be8d7a
Author:Dmitry Stogov Tue, 22 Mar 2016
23:57:26 +0300
Parents: 76d612129bb6b67171308f43c19d7e4791d7919e
Branches: master
Link:
http:
On Tue, Mar 22, 2016 at 7:11 PM, Andrea Faulds wrote:
> Hi Scott,
>
> Scott Arciszewski wrote:
>
>> PHP already offers bin2hex()/hex2bin() and
>> base64_encode()/base64_decode().
>> This covers part, but not all, of RFC 4648.
>>
>> I'd like to extend the coverage to include, at minimum, Base32.
>
Hi Scott,
Scott Arciszewski wrote:
PHP already offers bin2hex()/hex2bin() and base64_encode()/base64_decode().
This covers part, but not all, of RFC 4648.
I'd like to extend the coverage to include, at minimum, Base32.
Sounds good. It fills a gap and would doubtless be useful for some
applic
Hi again,
Apparently I misunderstood the parts of the RFC that I was most concerned
about (isset() and what causes magic method calls).
Joe clarified most of it for me elsewhere and so now I'll be answering my
own questions here, in case that helps anybody else:
On Tue, Mar 22, 2016 at 9:26 PM, A
Hi,
On Tue, Mar 22, 2016 at 9:52 PM, Pascal MARTIN, AFUP <
mail...@pascal-martin.fr> wrote:
> Le 09/03/2016 10:14, Yasuo Ohgaki a écrit :
>
>> Vote starts 2016-03-09-09:00(UTC) and ends 2016-03-23-09:00(UTC)
>> https://wiki.php.net/rfc/precise_session_management#vote
>>
>
> Hi,
>
> At AFUP, we wo
Le 09/03/2016 10:14, Yasuo Ohgaki a écrit :
Vote starts 2016-03-09-09:00(UTC) and ends 2016-03-23-09:00(UTC)
https://wiki.php.net/rfc/precise_session_management#vote
Hi,
At AFUP, we would be +1 on this RFC.
Basically: better security and pretty-much no bc-break, is a good thing.
Thanks for y
Hi all,
On Fri, Mar 18, 2016 at 9:30 PM, wrote:
> ---
> benchmark relative change since change since
> current rev run
> std_dev* last
Hi again,
Fleshgrinder wrote:
On 3/19/2016 9:32 PM, Andrea Faulds wrote:
Fleshgrinder wrote:
I see a big problem with the erroring no matter when as others already
pointed out, e.g. together with named constructors (or factory methods
if you prefer that name) but also with lazy loading. I thin
Hi Scott,
On Wed, Mar 23, 2016 at 3:29 AM, Scott Arciszewski wrote:
> PHP already offers bin2hex()/hex2bin() and base64_encode()/base64_decode().
> This covers part, but not all, of RFC 4648.
>
> I'd like to extend the coverage to include, at minimum, Base32.
>
> I'd also like to make these funct
Hi,
On Tue, Mar 22, 2016 at 9:23 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > be in the spirit of what was voted on to keep it (at least as an alias
> for
> > random_bytes()). However, that was not covered by what everyone voted
> for.
> > How would you like to proceed?
>
> I'd say keep it - either
On Tue, Mar 22, 2016 at 7:09 PM, Scott Arciszewski
wrote:
> On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs wrote:
>
>>
>>
>> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
>> wrote:
>>
>>> Hi all,
>>>
>>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>>
>>> The tally of closing (2016-03-2
Hi,
This mail turned out to look quite a lot like a rant - sorry about that. I
can assure you I am genuinely looking for answers on the questions that
follow ...
https://3v4l.org/Lq5dA/rfc#tabs (an example is from the RFC itself)
It doesn't make sense to me, for numerous reasons:
1. Why are any
No objections here.
On Mar 22, 2016 3:23 PM, "Stanislav Malyshev" wrote:
> Hi!
>
> > be in the spirit of what was voted on to keep it (at least as an alias
> for
> > random_bytes()). However, that was not covered by what everyone voted
> for.
> > How would you like to proceed?
>
> I'd say keep it
Hi!
> be in the spirit of what was voted on to keep it (at least as an alias for
> random_bytes()). However, that was not covered by what everyone voted for.
> How would you like to proceed?
I'd say keep it - either as an alias of as a function, doesn't matter.
It looks like common sense BC measu
Scott Arciszewski wrote on 22/03/2016 18:09:
1. emailintern...@lists.php.net to measure reaction to your intended
proposal.
This bit was definitely done, here:
http://marc.info/?l=php-internals&m=145218573626243&w=2
* Send email tointern...@lists.php.net introducing your RFC.
I did this
On 3/22/16 1:34 PM, Stephen Coakley wrote:
On 03/21/2016 11:09 PM, Levi Morrison wrote:
This requires you to query state with `isSome()`. This is hardly any
different from a null case, just more code. We can already accurately
distinguish between `null` and another value.
If we want an option f
On Tue, Mar 22, 2016 at 7:43 AM, Colin O'Dell wrote:
> This is a really interesting idea! However, I'm unsure whether it's wise
> to bring this feature in without having the community test and validate it
> first. Would it be possible to release this as an extension first so we
> can gauge its s
On 03/21/2016 11:09 PM, Levi Morrison wrote:
This requires you to query state with `isSome()`. This is hardly any
different from a null case, just more code. We can already accurately
distinguish between `null` and another value.
If we want an option for safer PHP code I think we need a safer
co
PHP already offers bin2hex()/hex2bin() and base64_encode()/base64_decode().
This covers part, but not all, of RFC 4648.
I'd like to extend the coverage to include, at minimum, Base32.
I'd also like to make these functions to be written to resist cache-timing
attacks (i.e. when used to encode/deco
On Tue, Mar 22, 2016 at 2:21 PM, Nikita Popov wrote:
> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
> wrote:
>
>> Hi all,
>>
>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>
>> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a
>> 79.3%
>> favorable response, which e
On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
wrote:
> Hi all,
>
> https://wiki.php.net/rfc/mcrypt-viking-funeral
>
> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3%
> favorable response, which exceeds the 2/3 majority by a significant margin.
>
> Thanks to everyo
On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs wrote:
>
>
> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
> wrote:
>
>> Hi all,
>>
>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>
>> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a
>> 79.3%
>> favorable response, wh
On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski
wrote:
> Hi all,
>
> https://wiki.php.net/rfc/mcrypt-viking-funeral
>
> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3%
> favorable response, which exceeds the 2/3 majority by a significant margin.
>
> Thanks to everyo
Hi all,
https://wiki.php.net/rfc/mcrypt-viking-funeral
The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a 79.3%
favorable response, which exceeds the 2/3 majority by a significant margin.
Thanks to everyone who voted or participated in this discussion.
I've heard and respect
Andreas Heigl wrote on 22/03/2016 16:25:
In the PHP 7 and typing presentations I've been giving[1], I've advocated
either:
>
>1) Throw an exception if the rest of the code is going to break anyway.
>2) Define an empty object with matching interface if you want an equivalent of
0/empty string.
On 3/22/16 11:25 AM, Andreas Heigl wrote:
Am 22.03.2016 um 15:56 schrieb Larry Garfield :
On 3/21/16 10:23 PM, Côme Chilliet wrote:
Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit :
But then I realized the problem. There
are many times where we need uncertainty. Code is a ref
> Am 22.03.2016 um 15:56 schrieb Larry Garfield :
>
>> On 3/21/16 10:23 PM, Côme Chilliet wrote:
>> Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit :
>>> But then I realized the problem. There
>>> are many times where we need uncertainty. Code is a reflection of reality,
>>> and
Björn Larsson wrote on 22/03/2016 15:04:
Hm... In Hack the above code works, see:
https://3v4l.org/nsA5W
Well they have a different implementation as mentioned in
the RFC, so no wonder. But they do have typed porperties in
the language.
It's not just a different implementation, it's a complet
Den 2016-03-22 kl. 14:15, skrev Rowan Collins:
Nikita Popov wrote on 21/03/2016 17:05:
While it is no secret that we don't particularly like references,
this is not the reason why they are forbidden. There is no conspiracy
to punish users of references by denying them use of new typing
feature
On 3/21/16 10:23 PM, Côme Chilliet wrote:
Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit :
But then I realized the problem. There
are many times where we need uncertainty. Code is a reflection of reality,
and as such, it must reflect uncertainty. NULL is a good enough way to
exp
Daniel,
This is a really interesting idea! However, I'm unsure whether it's wise
to bring this feature in without having the community test and validate it
first. Would it be possible to release this as an extension first so we
can gauge its stability and desirability in "the real world"?
As fa
On Tue, 22 Mar 2016 14:01:09 +0100, Craig Duncan wrote:
Why do you assume that Latte parser is limited by regexp ability to
parse
HTML?
Because it is:
https://github.com/nette/latte/blob/19b759b550caaad75ca0dee5f0d85f9ffb59c845/src/Latte/Parser.php#L124
No. That argument would only be
Nikita Popov wrote on 21/03/2016 17:05:
While it is no secret that we don't particularly like references, this
is not the reason why they are forbidden. There is no conspiracy to
punish users of references by denying them use of new typing features.
No, the reasons here are technical. Let me il
Results for project PHP master, build date 2016-03-22 06:28:02+02:00
commit: ac3a66c
previous commit:dab8e58
revision date: 2016-03-21 22:50:03+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
>
>
> Why do you assume that Latte parser is limited by regexp ability to parse
> HTML?
Because it is:
https://github.com/nette/latte/blob/19b759b550caaad75ca0dee5f0d85f9ffb59c845/src/Latte/Parser.php#L124
On Tue, 22 Mar 2016 13:32:58 +0100, Marco Pivetta
wrote:
On 22 March 2016 at 13:24, Jan Tvrdík wrote:
The escape context could be detected (e.g. Latte template engine
supports
context-aware escaping for years –
https://latte.nette.org/en/#toc-context-aware-escaping) but the logic is
quit
On 22 March 2016 at 13:24, Jan Tvrdík wrote:
> The escape context could be detected (e.g. Latte template engine supports
> context-aware escaping for years –
> https://latte.nette.org/en/#toc-context-aware-escaping) but the logic is
> quite complex for it to be included in PHP core.
Sorry, I h
On Mon, 21 Mar 2016 07:35:46 +0100, Daniel Beardsley
wrote:
Issue is "Escaping is done on a specific context".
I understand your proposal is focused on HTML escaping. However,
setting names like
__auto_escape_exempt_class
is not good choice. It has to be
__auto_html_escape_exempt_class
at le
Le 15/03/2016 17:11, Scott Arciszewski a écrit :
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e.
make it only installable via PECL).
Hi,
After discussing this RFC at AFUP, we would be +1 to depre
"Rowan Collins" wrote in message news:56efe897.3070...@gmail.com...
Daniel Beardsley wrote on 21/03/2016 06:35:
You are right. Though not all those problems are serious:
* URI escaping:
Does anyone really use or echo when generating a uri?
* Javascript:
Good point, though I would say it
Hi Yo-An Lin,
This "run-time inlining" approach may work.
PHP compiler (or optimizer) may mark functions and methods suitable for
"run-time" inlining (e.g. methods without arguments and FETCH_OBJ_R UNUSED,
CONST -> TMP; RETURN TMP).
Then INIT_METHOD_CALL may check this flag and execute "opti
43 matches
Mail list logo
