Hi Pierre,
On Sun, Feb 8, 2015 at 3:51 PM, Pierre Joye wrote:
> Not sure what this RFC is (did not dig the list as the link is wrong).
> However the latest on the topic is here and it is does not look
> remotely close to a approval:
>
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts
>
On Sun, Feb 8, 2015 at 1:43 PM, Yasuo Ohgaki wrote:
> Hi Pierre,
>
> On Sun, Feb 8, 2015 at 3:04 PM, Pierre Joye wrote:
>>
>> On Feb 8, 2015 12:48 PM, "Yasuo Ohgaki" wrote:
>>
>> >> 2. What's going to happen to mcrypt?
>> >>
>> >> I see the vote to excise it did not pass. Does this mean that (i.
Hi Pierre,
On Sun, Feb 8, 2015 at 3:04 PM, Pierre Joye wrote:
> On Feb 8, 2015 12:48 PM, "Yasuo Ohgaki" wrote:
>
> >> 2. What's going to happen to mcrypt?
> >>
> >> I see the vote to excise it did not pass. Does this mean that (i.e.
> >> imply that) PHP's plan is to keep a security lib that has
Hi Lester,
On Sat, Feb 7, 2015 at 9:36 PM, Lester Caine wrote:
> PHP7 is proposing a LOT of shiny new features which will break much
> legacy code. So the question has to be just what is the plan regarding
> cross version support. I see that the general consensus is PHP5 should
> just run?
>
Do
> ...cases that make sense to nearly everybody for abstract
> bondage-and-discipline notion
Well, the 50 Shades of Grey movie is coming out soon, so let's wait and see how
that does. :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 8, 2015 12:48 PM, "Yasuo Ohgaki" wrote:
>> 2. What's going to happen to mcrypt?
>>
>> I see the vote to excise it did not pass. Does this mean that (i.e.
>> imply that) PHP's plan is to keep a security lib that hasn't been
>> maintained for 8 years for the next 5+ years?
>
>
> Removed.
> A
Hi Tom,
On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster wrote:
> 1. Will there be a portable API for getting random bytes from the
> platform's CSPRNG?
>
> https://wiki.php.net/ideas/php6 lists as an addition: "Reliable,
> userfriendly RNG APIs: Provide a userfriendly and reliable RNG APIs,
> availa
On Sun, Feb 8, 2015 at 11:33 AM, Pierre Joye wrote:
>> > Yes, the RFC is somewhat inaccurate in that respect. It is per-file in
>> > one sense (like encoding, but unlike ticks, it has no effect on the
>> > including or included files). However, it technically affects the remainder
>> > of the fil
Hi!
> * Requiring an exact type match has the least mental overhead, and
> allows types to be checked at compile-time
What compile-time you're talking about? PHP has no "compile time".
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi!
> I don’t think it’s unfair. There’s a limited set of permitted
> conversions in some strictly-typed languages, but it’s still
> strictly-typed.
The main problem with strict typing as it is being proposed by
strictness proponents is exactly that - there's no limited set
permitted. It leads to
Hi,
> On 8 Feb 2015, at 03:52, Rasmus Lerdorf wrote:
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
>>> tan(1);
>>> echo strstr("test", "est", 1);
>>
>> Banning int->float and float->int is both a pain point and sometimes a
>> life-saver. It’s annoying that tan(1) doesn’t work. On the other
On Feb 8, 2015 10:52 AM, "Rasmus Lerdorf" wrote:
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
> >> tan(1);
> >> echo strstr("test", "est", 1);
> >
> > Banning int->float and float->int is both a pain point and sometimes a
life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, y
On 02/07/2015 09:51 PM, Andrea Faulds wrote:
>> tan(1);
>> echo strstr("test", "est", 1);
>
> Banning int->float and float->int is both a pain point and sometimes a
> life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you
> discover if your ints floats would be silently trunc
Hi,
> On 8 Feb 2015, at 02:51, Andrea Faulds wrote:
>
> Yes, the RFC is somewhat inaccurate in that respect. It is per-file in one
> sense (like encoding, but unlike ticks, it has no effect on the including or
> included files). However, it technically affects the remainder of the file,
> not
Hi Rasmus,
> On 8 Feb 2015, at 02:38, Rasmus Lerdorf wrote:
>
> On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
>> I'm wishing more and more that the RFC doesn't pass (even though I'd
>> LOVE to have typehints in PHP as a userland developer) and someone
>> else will make a better version of typehint
Thanks, with enabled opcache works fine.
On 7 February 2015 at 19:35, Christoph Becker wrote:
> Oleg Serov wrote:
>
> > I use !empty() very often and decided to make a benchmark test.
> >
> > Here is the code and results: http://pastebin.com/fMhhdQiW
> >
> > if (!empty(...)) working on 23% slowe
On Sun, Feb 8, 2015 at 9:38 AM, Rasmus Lerdorf wrote:
> On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
>> I'm wishing more and more that the RFC doesn't pass (even though I'd
>> LOVE to have typehints in PHP as a userland developer) and someone
>> else will make a better version of typehints RFC for
On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
> I'm wishing more and more that the RFC doesn't pass (even though I'd
> LOVE to have typehints in PHP as a userland developer) and someone
> else will make a better version of typehints RFC for PHP 7, because
> this one feels really like you took an ok-
Oleg Serov wrote:
> I use !empty() very often and decided to make a benchmark test.
>
> Here is the code and results: http://pastebin.com/fMhhdQiW
>
> if (!empty(...)) working on 23% slower than if (empty()) expression.
>
> So if create new operator not_empty() it will improve performance.
>
>
Hi Oleg,
this is already accomplished.
if (! )
would usually be compiled to:
1:
2: NOT
3: JMPZ -> 5
4:
5: ...
But OpCache's built-in optimizer
(https://github.com/php/php-src/blob/master/ext/opcache/Optimizer/block_pass.c)
is able to recognize this during the block level analysis and cre
I use !empty() very often and decided to make a benchmark test.
Here is the code and results: http://pastebin.com/fMhhdQiW
if (!empty(...)) working on 23% slower than if (empty()) expression.
So if create new operator not_empty() it will improve performance.
The first question is: What do you t
Hi,
> On 7 Feb 2015, at 22:03, Pavel Kouřil wrote:
>
> On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds wrote:
>> Hi,
>>
>>> On 7 Feb 2015, at 20:47, Andrea Faulds wrote:
>>>
On 7 Feb 2015, at 10:57, Pavel Kouřil wrote:
I just realized it now (I brought it up in a different man
On Sat, Feb 7, 2015 at 9:57 PM, Andrea Faulds wrote:
> Hi,
>
>> On 7 Feb 2015, at 20:47, Andrea Faulds wrote:
>>
>>> On 7 Feb 2015, at 10:57, Pavel Kouřil wrote:
>>>
>>> I just realized it now (I brought it up in a different manner when
>>> there was discussion about the RFC), but I didn't notic
Hi,
> On 7 Feb 2015, at 20:47, Andrea Faulds wrote:
>
>> On 7 Feb 2015, at 10:57, Pavel Kouřil wrote:
>>
>> I just realized it now (I brought it up in a different manner when
>> there was discussion about the RFC), but I didn't notice there was a
>> totally false statement about it in the RFC
Hi Pavel,
> On 7 Feb 2015, at 10:57, Pavel Kouřil wrote:
>
> On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds wrote:
>> Good evening,
>>
>> At long last, I’m going to put the RFC to a vote. It’s been long enough - I
>> don’t think there needs to be, or will be, much further discussion.
>>
>
>
I've been trying to catch up on the plans in PHP 7 for changes in security
features and APIs and I got confused. Questions on my mind at the moment
include:
1. Will there be a portable API for getting random bytes from the
platform's CSPRNG?
https://wiki.php.net/ideas/php6 lists as an addition: "
Hi Levi,
I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
have pushed off the removal to PHP 8, and instead only deprecate them
in PHP 7. The rationale is that eventual consistency in this matter is
good enough for now, and going slow may help avoid a Python 2 vs 3
type disa
On 07/02/15 11:07, Pierre Joye wrote:
> Please double check the RFC, what it does, propose and its impact by
> default on existing codes. Call it doing your homework. Then reconsider
> your reply.
There has always been a continual tread of 'you do not have to use it'
in a lot of what currently slo
My personal experience of PHP4 is simply one of having been developing
all my code in PHP5.0 to 5.2 but ensuring that the code also still run
clean on the PHP4 host. It was not until 5.3 that it was necessary to
freeze the code base for 5.2 for every PHP4 host and maintain that fork
while 'taking a
On Feb 7, 2015 6:46 PM, "Matteo Beccati" wrote:
>
> Hi Lars,
>
>
> On 07/02/2015 04:36, Lars Strojny wrote:
>>
>> My main concern is that the declare statement is
>> basically a better behaviour changing ini setting and PHPs history is
>> paved with those. I very much hope for scalar type hinting,
Try again ... last attempt just vanished :(
On 07/02/15 10:30, Benjamin Eberlei wrote:
> I hope this is the right pointer.
>
> The String API changed completely in ZE3, see the Upgrading docs to PHPNG:
>
> https://wiki.php.net/phpng-upgrading#strings
>
> It takes much time wrapping your head a
Hi Lars,
On 07/02/2015 04:36, Lars Strojny wrote:
My main concern is that the declare statement is
basically a better behaviour changing ini setting and PHPs history is
paved with those. I very much hope for scalar type hinting,
especially a strict variant but this is not what we should merge.
On Feb 7, 2015 5:01 PM, "Tony Marston" wrote:
>
> "Stelian Mocanita" wrote in message
news:CAMc0WS6+1Y-5yJW2s=mw+yns6tn8m5ieaxe10mwnlrl0_dz...@mail.gmail.com...
>
>>
>> On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans wrote:
>>
>>> The folks who really want all this great strict typing should head
On Feb 7, 2015 5:57 PM, "François Laupretre" wrote:
>
> > De : Pierre Joye [mailto:pierre@gmail.com]
> > Not sure it will help. It is really about showing cases for deref,
> > duplicate, convert, iterate, etc. The zpp, return values or
> > functions/class/methods declaration are really the eas
> De : Pierre Joye [mailto:pierre@gmail.com]
> Not sure it will help. It is really about showing cases for deref,
> duplicate, convert, iterate, etc. The zpp, return values or
> functions/class/methods declaration are really the easy part here.
I understand. I thought it would be a nice way to
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds wrote:
> Good evening,
>
> At long last, I’m going to put the RFC to a vote. It’s been long enough - I
> don’t think there needs to be, or will be, much further discussion.
>
Hello,
I just realized it now (I brought it up in a different manner when
On Sat, Feb 7, 2015 at 1:56 AM, Lester Caine wrote:
> OK slowly getting back into raw code again ...
>
> Looking at imagick phpinfo problem ...
>
> > if (supported_formats) {
> > for (i = 0; i < num_formats; i++) {
> > smart_string_appends(&formats,
> sup
( email addresses used to be easy! - get the right one )
On 07/02/15 02:34, Dan Ackroyd wrote:
> Lester,
>
> If you are having issues with Imagick please report them here:
> https://github.com/mkoppanen/imagick
>
> Not only is that the right place to report issues with unreleased
> versions of I
"Stelian Mocanita" wrote in message
news:CAMc0WS6+1Y-5yJW2s=mw+yns6tn8m5ieaxe10mwnlrl0_dz...@mail.gmail.com...
On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans wrote:
The folks who really want all this great strict typing should head over
to
Oracle.com and download free open-source Java? I hea
39 matches
Mail list logo
