On Fri, Apr 29, 2016 at 9:04 AM, Matt Wilmas wrote:
> Last June, it was briefly mentioned about changing PHP's string hash
> function [1] (DJB33 *seems* pretty horrible, after all, as far as
> collisions...). So 8 months ago I tried almost, if not, a half-dozen of
> them (including Murmur3) that
Morning David,
To confirm it was something to do with opcache, I removed opcache from
the source tree:
krakjoe@fiji:/usr/src/php-src$ ./configure --disable-all | grep static
checking if cc static flag -static works... yes
checking whether to build static libraries... yes
That
> This needs to be agreed in the core first
Meh, no. Let someone that actually worked for years and years on the
specific problem to solve that, please: accumulated experience across all
use-cases is the best resource you can get here, and he knows his stuff.
> Is composer now the only supporte
Hey,
> Am 29.4.2016 um 02:04 schrieb Matt Wilmas :
>
> Hi all,
>
> Last June, it was briefly mentioned about changing PHP's string hash
> function [1] (DJB33 *seems* pretty horrible, after all, as far as
> collisions...). So 8 months ago I tried almost, if not, a half-dozen of
> them (including
Now, after seeing Bogdan's hash optimization idea last month [2], and
reading Nikita's blog post [3] again, I had some ideas I'd like to try --
assuming nobody else is planning major changes. :-) Besides Nikita, I'm
addressing Dmitry and Xinchen because your names are on some minor hash
items on
Hi all,
Last June, it was briefly mentioned about changing PHP's string hash
function [1] (DJB33 *seems* pretty horrible, after all, as far as
collisions...). So 8 months ago I tried almost, if not, a half-dozen of
them (including Murmur3) that were simple enough to quickly toss in.
The result?
Hi,
The PHP development team announces the immediate availability of PHP 7.0.6.
This is a security release. Several security bugs were fixed in this
release, including
- CVE-2016-3078
- CVE-2016-3074
All PHP 7.0 users are encouraged to upgrade to this version.
For source downloads of PHP 7.0.6
Hello!
The PHP development team announces the immediate availability of PHP 5.6.21.
Several security related issues were fixed in this release. All
PHP 5.6 users are encouraged to upgrade to this version.
For source downloads of PHP 5.6.21 please visit our downloads page:
http://www.php.net/downl
On 20.03.2016, at 22:10, David Zuelke wrote:
>
> On 10.03.2016, at 16:56, David Zuelke wrote:
>>
>>> On 08.03.2016, at 16:18, Andrea Faulds wrote:
>>>
>>> Hi,
>>>
>>> David Zuelke wrote:
Is this intentional? Related to opcache's "can only be built shared"
status? But why would tha
On 4/28/16 4:41 PM, Björn Larsson wrote:
Can't resist jumping into this discussion, but when I first read
both RFC's, I found them quite complementary.
In one sense, I agree. But when it comes to the question: let's vote on
the options to decide what, if anything, happens to PHP, they are
op
I seem to have created some confusion here:
The reason _my_ patch for Server Push isn't merged is tests for it were
requested and are blocking it. I'm not saying tests for these constants
should be added.
- Davey
On Wed, Apr 27, 2016 at 4:15 PM, Pierrick Charron wrote:
> Sorry for the 2 mails
More or less right. It's easy to archive the "right" goal, if you own the both
football teams.
From: Tom Worster
Sent: Thursday, April 28, 2016 11:40:53 PM
To: Levi Morrison; Dmitry Stogov
Cc: internals
Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's
Hi!
> I personally think that such a system should be implemented directly in
> the language, like Eiffel has it. I even think that it would be easy to
I think we should not try to be Haskell, Scala and Eiffel at the same
time. DbC is not something most of the users of the language require and
wo
Levi,
>From one reasonable point of view, Union and Nullable are in conflict with
each other. If one prefers Union then one might argue in favor of Union
over related but different proposals. When it comes to the vote, it's
difficult to support both except with the argument that "I can settle for
Hi,
Can't resist jumping into this discussion, but when I first read
both RFC's, I found them quite complementary. I was actually a
bit tempted to combine them into one just as a writing exercise
for my self (wanted to train on writing RFC's).
My suggestion would be that you merge them into one
Fleshgrinder wrote on 28/04/2016 20:20:
On 4/28/2016 8:02 PM, Rowan Collins wrote:
Interesting; do you have a link to where this terminology is explained?
Most of the articles I've seen just refer to "attributes", and the link
you have doesn't really explain that at all, it has namespaces with
"
Is there a reason why you think that Design by Contract (DbC) should be
implemented via annotations/attributes?
I personally think that such a system should be implemented directly in
the language, like Eiffel has it. I even think that it would be easy to
add it without any BC. It might be a bit m
I figured class methods would be a problem, especially if it were
implemented at compile time as the compiler wouldn't necessarily know which
class it refers to.
Curious though, which part of the function call causes the performance hit?
I've noticed that the number of parameters it has contribute
This is not a default value (i.e. you can use = null in middle of required
parameters), but defacto a nullable parameter type.
Default values should and will always be changeable between functions in an
inheritance tree.
And while it's a tiny BC break, one can very easily fix the function from
f
On 4/28/2016 8:02 PM, Rowan Collins wrote:
> Interesting; do you have a link to where this terminology is explained?
> Most of the articles I've seen just refer to "attributes", and the link
> you have doesn't really explain that at all, it has namespaces with
> "annotation" in the name, but uses t
Levi, I provided an implementation for your RFC on February 2015, and I would
be glad if your RFC was accepted that time.
Bit since that time you block it in respect to "Union Types"
See conversation at PR https://github.com/php/php-src/pull/1045
I would be also glad if your "Nullable Types" RFC
On Thu, Apr 28, 2016 at 12:54 PM, Dmitry Stogov wrote:
> Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC,
> if you like completely different "Union Types".
I don't understand; I wrote the RFC. What do you mean, "keep trying to
own" it? I wrote both Nullable Types and
On Thu, Apr 28, 2016 at 8:39 PM, Dominic Grostate <
codekest...@googlemail.com> wrote:
> That sounds wicked. I look forward to benchmarking it and seeing how its
> done.
> On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote:
>
> > On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate
> > wrote:
> > > As
Levi, I don't understand, why do you keep trying to own "Nullable Types" RFC,
if you like completely different "Union Types".
From: morrison.l...@gmail.com on behalf of Levi
Morrison
Sent: Thursday, April 28, 2016 9:47:18 PM
To: Joe Watkins
Cc: Dmitry S
On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins wrote:
> Levi,
>
> Why do you need to block Dmitry's return type nullable RFC ?
>
> We need to move forward, that has an implementation, ready for a long
> time, doesn't seem to block nullable parameter types rfc, either separately
> or as part
That sounds wicked. I look forward to benchmarking it and seeing how its
done.
On 28 Apr 2016 6:39 p.m., "Sara Golemon" wrote:
> On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate
> wrote:
> > As I understand it, the process by which the call stack is updated and
> > scope changed, is quite expe
PHP method compatibility rules didn't take into account default values of
arguments.
Adding new rule is not just a bug fix, and breaks existing code.
From: Bob Weinand
Sent: Thursday, April 28, 2016 9:12:54 PM
To: Dmitry Stogov
Cc: Anatol Belski; Joe Watk
Yeah,
It's a BC break; hence I've accepted it being reverted from 7.0.
I've only put the fix back in 7.1 thus.
Or is it your opinion that we shall hold a formal RFC vote for a glaring bug?
That sounds pretty much like a waste of everyones time to me. RFC votes IMO are
for cases where we don't ha
Fleshgrinder wrote on 28/04/2016 18:33:
Actually Microsoft got it exactly right and they are explaining in depth
what I wrote as well. The result of an annotation is an attribute. So it
is only natural to call the classes attributes.
public class Customer {
[DataType(DataType.EmailAddre
This is a "fix", that introduces BC break.
Even if I see a reason in this check, it's still a break.
If you remember, we voted for almost for every BC break during PHP-7.0
development.
From: Bob Weinand
Sent: Thursday, April 28, 2016 8:36:22 PM
To: Dmitr
Levi,
Why do you need to block Dmitry's return type nullable RFC ?
We need to move forward, that has an implementation, ready for a long
time, doesn't seem to block nullable parameter types rfc, either separately
or as part of unions.
So, I'm not understanding why you need to hold up
I'm not happy with the fact, that you propose two competing RFCs, support only
one and trying to withdraw other competitors.
From: morrison.l...@gmail.com on behalf of Levi
Morrison
Sent: Thursday, April 28, 2016 8:47:41 PM
To: Dmitry Stogov
Cc: interna
all these are good points not to commit BC breaks in hurry.
From: Joe Watkins
Sent: Thursday, April 28, 2016 8:41:34 PM
To: Bob Weinand
Cc: Dmitry Stogov; Anatol Belski; internals; Levi Morrison
Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types f
On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov wrote:
> your Nullable RFC doesn't propose working implementation.
>
>
> From: morrison.l...@gmail.com on behalf of Levi
> Morrison
> Sent: Thursday, April 28, 2016 8:39:03 PM
> To: Dmitry Stogov
> Cc: inte
> Am 28.04.2016 um 19:28 schrieb Dmitry Stogov :
>
> hi Joe,
>
>
> No problem, great it's fixed before 7.0.6 release.
>
> I think this change might be introduced only together with nullable or union
> types.
>
> Otherwise it makes a problem, described by Levi, that doesn't allow running
> t
your Nullable RFC doesn't propose working implementation.
From: morrison.l...@gmail.com on behalf of Levi
Morrison
Sent: Thursday, April 28, 2016 8:39:03 PM
To: Dmitry Stogov
Cc: internals; Tom Worster
Subject: Re: Request to withdraw RFC's for nullable
On 4/27/2016 11:36 PM, Lester Caine wrote:
> To add to your list ...
> https://www.phpdoc.org/docs/latest/guides/docblocks.html
>
> The glossary entry is rather bare, but I would dispute THEIR statement -
> "but also influences the way the application behaves."
>
> In my book, these comment block
The problem is as Levi explained though Bob, don't we actually require
nullables/unions for that case ?
Maybe we can move forward now, confident that by the time 7.1 is released
we will have one of those things ?
The problems with that are, the RFC's for unions/intersections don't match
the imple
On Thu, Apr 28, 2016 at 1:21 AM, Dominic Grostate
wrote:
> As I understand it, the process by which the call stack is updated and
> scope changed, is quite expensive. And from tests I can see that function
> calls do actually add a not insignificant overhead to intensive repetitive
> tasks.
>
> S
On Thu, Apr 28, 2016 at 11:07 AM, Dmitry Stogov wrote:
> Thanks for catching the BC break.
> Fortunately, we didn't release 7.0.6 with this problem.
>
> I see some sense in introducing that check, but changing behaviour requires
> RFC and definitely not allowed in minor versions.
>
> I'm not goin
> Am 28.04.2016 um 18:28 schrieb Dmitry Stogov :
>
> Hi,
>
> The BC break in PHP-7.0 was introduced by commit
> ee9a78a033696ff9546fb1dbfecd28f20477b511
>
> Author: Joe Watkins
> Date: Mon Mar 28 11:54:25 2016 +0100
>
> Late, there were few more commits that changed and moved the problema
On 4/28/2016 11:36 AM, Rowan Collins wrote:
> While I personally prefer the name "annotations", I don't see it as
> particularly urgent, or nearly as clear-cut as you claim.
>
That's okay and why we are discussing things. ;)
On 4/28/2016 11:36 AM, Rowan Collins wrote:
> I clicked through on your
hi Joe,
No problem, great it's fixed before 7.0.6 release.
I think this change might be introduced only together with nullable or union
types.
Otherwise it makes a problem, described by Levi, that doesn't allow running the
same code in PHP-7.0 and 7.1, and even doesn't allow an ease fix.
Th
Evening Dmitry,
This was discussed at length with bob, and I think nikita also, it seemed
like a bug fix rather than a feature.
Happy for it to be moved into 7.1 ... sorry for dropping the ball there ...
Cheers
Joe
On Thu, Apr 28, 2016 at 6:07 PM, Dmitry Stogov wrote:
> Thanks for catching th
Thanks for catching the BC break.
Fortunately, we didn't release 7.0.6 with this problem.
I see some sense in introducing that check, but changing behaviour requires RFC
and definitely not allowed in minor versions.
I'm not going to withdraw https://wiki.php.net/rfc/nullable_return_types
It does
Hi,
The BC break in PHP-7.0 was introduced by commit
ee9a78a033696ff9546fb1dbfecd28f20477b511
Author: Joe Watkins
Date: Mon Mar 28 11:54:25 2016 +0100
Late, there were few more commits that changed and moved the problematic code.
Anatol, I think we should revert this before 7.0.6 release.
Bob Weinand wrote on 28/04/2016 16:49:
Regarding your suggestion, $foo instanceof Foo & Bar is conflicting with bitwise and
here. Anyway, you already can $foo instanceof Foo && $foo instanceof Bar. Which is
IMO just as easy, not conflicting and more flexible.
It's a shame that that's so verb
I have discovered through a [bug report][1] a case where having
explicitly nullable parameters would be of value.
You can theoretically change the default value in a sub-type, but in
this case moving away from the default value of null breaks because
the subtype no longer permits null. It is imp
> Am 28.4.2016 um 17:11 schrieb guilhermebla...@gmail.com:
>
> Nice!
>
> I've read the RFC and there's only one missing thing that is either
> undocumented or missed during patch creation: instanceof.
> I'd be amazing if we could do: $foo instanceof Foo & Bar
>
> Cheers,
>
> On Thu, Apr 28, 20
Nice!
I've read the RFC and there's only one missing thing that is either
undocumented or missed during patch creation: instanceof.
I'd be amazing if we could do: $foo instanceof Foo & Bar
Cheers,
On Thu, Apr 28, 2016 at 5:00 AM, Josh Di Fabio
wrote:
> On Thu, Apr 28, 2016 at 4:54 AM, Levi Mor
Results for project PHP master, build date 2016-04-28 15:53:03+03:00
commit: 6499162
previous commit:e88c71d
revision date: 2016-04-28 04:13:34+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Lester Caine wrote on 28/04/2016 08:21:
On 28/04/16 06:35, Marco Pivetta wrote:
This is what Mike van Riel was working on with PSR-5. Work has been
suspended atm, but I'd still go look at that first.
Sorry but php-fig is not PHP and sme of the 'standards' created there
are at odds with the pref
Fleshgrinder wrote on 27/04/2016 21:11:
I am writing this in a separate thread because of the urgency that I see
regarding the naming of past, current, and future proposals regarding
this functionality.
While I personally prefer the name "annotations", I don't see it as
particularly urgent, or
On Thu, Apr 28, 2016 at 4:54 AM, Levi Morrison wrote:
> Internals,
>
> As alluded to last week I have another RFC for improving the type
> system: [intersection types][1].
>
> It allows parameters to define multiple type constraints that must be
> satisfied. Common combinations of our built-in typ
Something in Dmitry's attribute RFC caught my attention. There is an
example implying inline functions indicated by an attribute.
I know that was only a potential use case for an extension. But it made me
wonder how much that could improve PHPs performance if we actually had it.
As I understand
On 28/04/16 06:35, Marco Pivetta wrote:
> This is what Mike van Riel was working on with PSR-5. Work has been
> suspended atm, but I'd still go look at that first.
Sorry but php-fig is not PHP and sme of the 'standards' created there
are at odds with the preferred practices in the PHP code ... whi
56 matches
Mail list logo