Results for project PHP master, build date 2017-05-29 19:24:10-07:00
commit: 37a16a3
previous commit:85b0b8a
revision date: 2017-05-29 12:07:13+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Den 2017-05-31 kl. 00:26, skrev Levi Morrison:
On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
wrote:
Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
On Tue, 30 May 2017, Levi Morrison wrote:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a n
On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
wrote:
> Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
>
>> On Tue, 30 May 2017, Levi Morrison wrote:
>>
>>> Internals,
>>>
>>> The previous discussion thread has died down significantly and so I'd
>>> like to start a new one to refocus. This messag
Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
On Tue, 30 May 2017, Levi Morrison wrote:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redundant
information by design so people don't have to referenc
Rowan Collins schrieb am Di., 30. Mai 2017, 19:39:
> On 30/05/2017 07:24, Rasmus Schultz wrote:
> >> The type widening RFC makes it easier to move to parameter types for
> > existing libraries.
> >
> > I'm curious to see how you'll set the version constraint in your
> > composer.json file.
>
>=m
On Mon, May 29, 2017 at 9:16 PM, Niklas Keller wrote:
> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka :
>
>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller wrote:
>>
>>> Morning Internals,
>>>
>>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>>
>>>
>> Wouldn't be better use
On Tue, May 30, 2017 at 6:51 AM, Niklas Keller wrote:
>
> do you know how I can check whether a certificate is in the trust store or
> not?
>
>
I guess it depends what you want to do. If you want to check if the cert is
in cert store loaded in the SSL struct, then you could get it using
SSL_get_c
On Tue, 30 May 2017, Levi Morrison wrote:
> Internals,
>
> The previous discussion thread has died down significantly and so I'd
> like to start a new one to refocus. This message has some redundant
> information by design so people don't have to reference the other
> thread so much.
>
> Based o
On 5/30/2017 9:26 PM, Stanislav Malyshev wrote:
> Hi!
>
> Sorry if it sounded that way, I of course meant nothing like it. I just
> meant that introducing docs standard should not be made in a routine
> unrelated patch, where it could be missed by many people, but as an
> ordered process. Otherwis
Hi!
>> But randomly introducing docs system without any explicit decision in an
>> unrelated patch doesn't look like a good idea to me.
>>
>
> Wow! This sounds like you think that I am trying to deliberately
> sabotaging the PHP project. Quite the opposite is the case. I am simply
Sorry if it so
Den 2017-05-30 kl. 20:24, skrev Levi Morrison:
On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
wrote:
Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redun
>> You mentioned ability to explicitly specify binding as a possible extension.
>> However
>>
>> [$var1, $var2]()
>>
>> is not necessarily failing right now, it may be a valid array callable.
>>
>> Nikita
>
> As already mentioned we must maintain a leading `=` or `&`:
>
> [=, $var1, $var2]()
Hey Jefferson!
On 5/30/2017 2:04 AM, Jefferson Gonzalez wrote:
> Hi,
>
> It seems that five years ago I was chatting on the php.internals irc and
> I was asking wether documenting the source code with doxygen was
> something that it could be worked on, but it seems that most core
> developers whe
On Tue, May 30, 2017 at 12:36 PM, Nikita Popov wrote:
> On Tue, May 30, 2017 at 8:24 PM, Levi Morrison wrote:
>>
>> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
>> wrote:
>> > Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
>> >>
>> >> Internals,
>> >>
>> >> The previous discussion thread has
On Tue, May 30, 2017 at 8:24 PM, Levi Morrison wrote:
> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
> wrote:
> > Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
> >>
> >> Internals,
> >>
> >> The previous discussion thread has died down significantly and so I'd
> >> like to start a new one to
On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
wrote:
> Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
>>
>> Internals,
>>
>> The previous discussion thread has died down significantly and so I'd
>> like to start a new one to refocus. This message has some redundant
>> information by design so pe
Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redundant
information by design so people don't have to reference the other
thread so much.
Based on the disc
Den 2017-05-30 kl. 17:09, skrev Levi Morrison:
Well, my preference would be for alternative 3. Not in favour of 2 & 4.
Nr 1 not so sure about and for nr 5, maybe tweak it to:
- [](params) ==> expr// binds no values
- [=](params) ==> expr// binds by value
- [&](params) ==> expr// bind
Internals,
The previous discussion thread has died down significantly and so I'd
like to start a new one to refocus. This message has some redundant
information by design so people don't have to reference the other
thread so much.
Based on the discussion there are a few different syntax choices
p
Hey Stas!
On 5/30/2017 12:50 AM, Stanislav Malyshev wrote:
> Hi!
>
>> I used Doxygen in both PRs to document the code. Right now the code base
>> is lacking a lot of documentation, which, if done right, would greatly
>> improve accessibility of the code base.
>
> Well, the problem as I understan
@Tony: exactly what Rowan said. We will not change a single line of
code, and nobody will be forced to do anything. **UNLESS** the code is
meant to become part of the core of PHP. In that case it must follow the
rules, the rules that are part of the coding standard. It is fine if you
change your co
Hey Stas!
On 5/30/2017 1:00 AM, Stanislav Malyshev wrote:
> Hi!
>
>> People are complaining over at Reddit [1]
>
> Isn't it what Reddit is for? ;)
>
I guess it is. ;)
>> I know that this is probably a topic nobody cares much about, at least
>> we did not end up in this kind of bikeshedding in
On 30/05/2017 07:24, Rasmus Schultz wrote:
The type widening RFC makes it easier to move to parameter types for
existing libraries.
I'm curious to see how you'll set the version constraint in your
composer.json file.
After adding a scalar type-hint to an interface, which is a breaking change
i
> Well, my preference would be for alternative 3. Not in favour of 2 & 4.
> Nr 1 not so sure about and for nr 5, maybe tweak it to:
> - [](params) ==> expr// binds no values
> - [=](params) ==> expr// binds by value
> - [&](params) ==> expr// binds by reference
Can you explain why you
On Tue, 30 May 2017, Tony Marston wrote:
> "Rowan Collins" wrote in message
> news:dc66f890-a033-4efa-8f2b-cb365c8a4...@gmail.com...
> >
> > On 30 May 2017 09:21:38 BST, Tony Marston wrote:
> >
> > > Different projects/teams/organisations are free to use whatever
> > > naming convention they l
"Rowan Collins" wrote in message
news:dc66f890-a033-4efa-8f2b-cb365c8a4...@gmail.com...
On 30 May 2017 09:21:38 BST, Tony Marston wrote:
Different
projects/teams/organisations are free to use whatever naming convention
they
like, be it snake_case, CamelCase, studlyCaps or whatever
I think t
On 30 May 2017 09:30:02 BST, "Björn Larsson" wrote:
>I presume then that the options discussed earlier "|params| => expr"
>and "lamda(params) => expr" are of the table.
I'm a fan of "lambda(params) => expr" myself, because unlike "fn", it makes it
clear that this is a *new type of definition*, n
On 30 May 2017 09:21:38 BST, Tony Marston wrote:
> Different
>projects/teams/organisations are free to use whatever naming convention
>they
>like, be it snake_case, CamelCase, studlyCaps or whatever
I think the discussion here is which convention we, as the PHP Internals
project/team/organisat
Am 30.05.17 um 11:45 schrieb Côme Chilliet:
> Hello,
>
> Just to be sure, in which branches/versions should a PR like this one get
> merged: https://github.com/php/php-src/pull/2536 ?
>
> Côme
>
IMHO that's a bug-fix, not a security-issue, so master, 7.1 and 7.0
Cheers
Andreas
--
Hello,
Just to be sure, in which branches/versions should a PR like this one get
merged: https://github.com/php/php-src/pull/2536 ?
Côme
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 05/30/17 10:23, Nikita Popov wrote:
> On Tue, May 30, 2017 at 9:11 AM, Martijn van Duren
> wrote:
>
>> Hello internals@,
>>
>> I'm new to this list, so let me first introduce myself.
>> My name is Martijn van Duren and I work for a webhosting company in the
>> Netherlands. Apart from that I'm
Den 2017-05-30 kl. 04:48, skrev Levi Morrison:
On Mon, May 29, 2017 at 4:47 AM, Björn Larsson
wrote:
Den 2017-04-05 kl. 23:57, skrev Levi Morrison:
Any plans to go with this for 7.2?
I have been working on this RFC a bit in the last two weeks and intend
to start voting within the next week.
On Tue, May 30, 2017 at 9:11 AM, Martijn van Duren
wrote:
> Hello internals@,
>
> I'm new to this list, so let me first introduce myself.
> My name is Martijn van Duren and I work for a webhosting company in the
> Netherlands. Apart from that I'm also an OpenBSD h^Hslacker.
>
> tl;dr:
> How do I
wrote in message
news:9dffe898-e550-c6d6-46bd-86dcf7473...@fleshgrinder.com...
Hey guys!
People are complaining over at Reddit [1] about using PHP, Std, UUID,
... in other words about case.
I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of
Hello internals@,
I'm new to this list, so let me first introduce myself.
My name is Martijn van Duren and I work for a webhosting company in the
Netherlands. Apart from that I'm also an OpenBSD h^Hslacker.
tl;dr:
How do I properly use Z_REFCOUNT on a zval?
I'm faced with the following issue:
I'
35 matches
Mail list logo
