Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Tom Worster]

On 1/14/16, 9:37 AM, "Pierre Joye"  wrote:

>I think we get every one point about where we stand, between the
>people against a CoC, against a CoC with teeth etc.

I wasn't talking about the Code of Conduct. Different topic.
 


>This is getting
>nowhere and we are really off topic.
>
>I would suggest to stop talking in circle for now and wait the next
>version of the RFC. Then we can focus on the content of the CoC, let
>me rephrase that, then we can focus only on the content of the CoC and
>the eventual "CoC group" and its role.




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC][VOTE] Number Format Separator

[Thomas Punt]

Hi Björn,

> Well, if I had a vote it would definetly be +1. A small question
> though, why is the voting period only one week (small RFC or)?

The RFC is quite simple and short, so I thought a one week voting period would
suffice. I'm more than happy to extend this though if people don't think they'll
have time to review it within the next week.

> Regards //Björn Larsson

-Tom  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Number Format Separator

[Björn Larsson]

Den 2016-01-14 kl. 18:21, skrev Thomas Punt:

Hi Björn,


Well, if I had a vote it would definetly be +1. A small question
though, why is the voting period only one week (small RFC or)?

The RFC is quite simple and short, so I thought a one week voting period would
suffice. I'm more than happy to extend this though if people don't think they'll
have time to review it within the next week.


Regards //Björn Larsson

-Tom

Well, even if it's small one there could be a value in having a slightly
longer voting period. Just thought that many CoC mails on the list
now takes focus.

Still, no point in making a hen out of a feather :-)

Regards //Björn

PS I'm not sure the RFC process allows to change voting period
once the voting is opened.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #68063

[Julien Pauli]

On Wed, Jan 13, 2016 at 12:03 AM, Stanislav Malyshev
 wrote:
> Hi!
>
>> I've disallowed empty session ID, but it wasn't a
>> appropriate fix.
>>
>> https://bugs.php.net/bug.php?id=68063
>
> Could you explain a bit more about the part where there are empty IDs
> generated? You say it "is browser's cookie handling" - could you explain
> more about it?
>
>> I made appropriate patch for this issue. It should be
>> applied from PHP 5.5 to master. I attached patch to
>> the bug report. Could you apply it from PHP 5.5? Or
>> shall I commit it from 5.6? then cherry pick?
>
> Is that a security issue? If so, please explain how. If not, it should
> be 5.6+.

IMO, this is not security related.


Julien.Pauli

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-01-14

[lp_benchmark_robot]

Results for project PHP master, build date 2016-01-14 06:30:47+02:00
commit: 092a87c
previous commit:bef1245
revision date:  2016-01-13 21:32:38+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.23%  0.13%  0.54%  
  6.63%
:-|   Drupal 7.36 cgi -T1  0.19%  0.27%  0.26%  
  4.08%
:-|   MediaWiki 1.23.9 cgi -T5000  0.13%  0.57%  1.75%  
  2.41%
:-|   bench.php cgi -T100  0.01%  0.51%  0.93%  
  5.93%
:-|  micro_bench.php cgi -T10  0.02%  0.56%  0.62%  
  3.66%
:-|  mandelbrot.php cgi -T100  0.02% -0.80%-12.53%  
 -1.04%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-01-14/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #68063

[Yasuo Ohgaki]

Hi Julien,

On Thu, Jan 14, 2016 at 7:21 PM, Julien Pauli  wrote:
> On Wed, Jan 13, 2016 at 12:03 AM, Stanislav Malyshev
>  wrote:
>> Hi!
>>
>>> I've disallowed empty session ID, but it wasn't a
>>> appropriate fix.
>>>
>>> https://bugs.php.net/bug.php?id=68063
>>
>> Could you explain a bit more about the part where there are empty IDs
>> generated? You say it "is browser's cookie handling" - could you explain
>> more about it?
>>
>>> I made appropriate patch for this issue. It should be
>>> applied from PHP 5.5 to master. I attached patch to
>>> the bug report. Could you apply it from PHP 5.5? Or
>>> shall I commit it from 5.6? then cherry pick?
>>
>> Is that a security issue? If so, please explain how. If not, it should
>> be 5.6+.
>
> IMO, this is not security related.

Strictly speaking, it's not. IMO.

However, previous my fix (Raise warning and return false) was wrong fix.
Therefore, I would like to correct (Provide new session ID and continue)
it in 5.5 also. Does this make sense?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Zeev Suraski]

> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Wednesday, January 13, 2016 9:46 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines --
> "let's proceed to ideas"


> There's an important point we've been glossing over here that I think is
> important to make explicit, as it is part of the reticence people have about
> CoCs, "culture change", etc.  That all presupposes that there are problems,
> which means that fixing them implies some people's behavior will need to
> change.  People don't like needing to change their behavior (regardless of
> whether that behavior is subjectively "good" or "bad").

I view this a bit differently.

First, I think saying something like "People will have to change" is not a good 
description of what we're after.  If we're going to declare something along the 
lines of 'New rules here, you're going to have to change' - then yes, I think 
we're going to have a very hard time - both in getting buy-in, and in terms of 
the likelihood of this whole thing actually resulting in transforming the 
atmosphere on internals for the better.  I also don't think we need to create 
unanimous agreement that 'there is a problem'.  That's the wrong first step - 
as it creates controversy from the get go (as it already did).  The way I see 
it, we don't need to acknowledge having a problem in order to want to improve.  
I'm sure that resonates with most developers on this list - wanting to 
continuously improve does not mean you're saying that things were problematic 
to begin with.  Instead, it's an assumption which is literally always true - 
wherever you are, whatever you do, you can always do better.  It's true for 
everything - processes, relationships, code - and mailing list etiquette.

The right question, IMHO, is do we want to improve?  Do we want to try and be 
more polite and respectful?  Do we want to try and improve the atmosphere?  
That's a much easier goal to rally around, I think, and for the most part, I 
can hardly imagine there won't be consensus around it. 

> Many lists I'm on, particularly those with high churn, send out an email every
> month automatically with list rules et al.  98% of people won't bother reading
> them 98% of the time, but for the first time you see it it's an indication of 
> "oh,
> yeah, they've code some expectations in place, maybe I'll read them" and for
> subsequent times it's a reminder of "oh yeah, that thing, it exists."  Similar
> idea to the company (I forget
> which) that has the company principles printed out in everyone's cube to
> read over every morning.

Something along the lines of this should be at least a part of the solution, I 
think.  Continuing the point I made above, instead of having a laundry list of 
what not to do - we should focus on the values and behavior we want to 
encourage  - positive expectations.  I wouldn't call them 'rules', either, but 
guidelines, such as Please Be Respectful, or 'Please don't do to others would 
you wouldn't want others to do to you'.  Humans tend to react negatively when 
they're forced to do something, and much better when they're encouraged to do 
it - especially as we don't want to go in the direction of sanctions.  If we 
end up having a mediation team (not the CR team, but a team whose pure job is 
to mediate) - I think it would be fair for it to jump in in case it sees a 
discussion going south or a certain person that's going against the spirit of 
these values - and I believe that in the vast majority of cases, it would be 
more than enough for them to cool off.  Ultimately I think most people want to 
improve.

The other part, IMHO, is minimizing contentious topics, even if it's at the 
price of doing less.

> That email would include either the text of or links to a "list rules"
> doc (which is not necessarily easy to find as is), a link to a CoC should one
> pass, etc.  Keep it reasonably short, but having it in-your-face for even a 
> few
> seconds once a month can be helpful over time.
> 
> > Finally, I remarked yesterday that the current Internals culture
> > serves a political purpose: to support the existing power hierarchy.
> > That's rather pessimistic but there remains hope if one believes power
> > can be exerted effectively through good conduct.
> 
> ^^ This.

If we do end up having a laundry list of what not to do, would it include not 
making vague statements that imply accusations? :)

Zeev

RE: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

[Zeev Suraski]

> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Tuesday, January 12, 2016 12:55 AM
> To: David Zuelke 
> Cc: Stanislav Malyshev ; Pierre Joye
> ; Brandon Savage ;
> Larry Garfield ; PHP internals
> 
> Subject: Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct
> 
> Zeev,
> 
> > What clearly hasn't happened is any proponent of this RFC actually
> answering these questions.
> 
> Because I (and others) believe that none of these questions are actually
> related to the RFC. They are tangential and are distractions from the prime
> point. The prime point is to actually figure out is where we should move the
> proposal towards. Very few of the replies, and none of the ones in the past
> 100 replies discuss this prime point.

That's a way of answering too!  Now that I know that's your position, I can 
tell you what I think about it.  Going back to the questions as you phrased 
them:

>> Some people have
>> questioned what this is a solution to, but most haven't.

Actually, that brings me to one of my main gripes with the RFC - the extremely 
widespread confusion surrounding it.  In this case, the fact people aren't 
questioning what this is a solution to, does not in any way mean they 
understand what it's trying to solve.  In fact, everything I've seen in the 
last few days, and everyone I've spoken to, leads me to believe the exact 
opposite.  For the most part, people think it's supposed to solve the 'toxic 
internals' problem.  While you've since gone on record that's not the case - 
it's buried in a long reply to me;  I think it should be a prominent part of 
the RFC at the very least - and proponents of the RFC should be going out of 
their way to ensure that it's clear to everyone this is not what this RFC is 
aiming to do (as noble a cause as it may be).  This widespread confusion is one 
of the key sources for opposition to this RFC, since people believe its goal 
would be creating a behavior or thought police. 

>> Some have questioned if we have a problem, but most haven't.
 
As I said before I wouldn't assume that just because people asking - they don't 
want to see this answered.

> IMHO answering these meta level questions, and having this meta level
> discussion is a distraction from the entire point of the proposal.

Even if that's your position - when RFC authors see questions coming up 
repeatedly from various people, I believe they must respond to them even if the 
response is that these questions are beside the point, with an explanation as 
to why they're beside the point in their opinion.

I don't believe these questions are meta at all.  Ultimately, I think whether 
or not this RFC is worth the risk it poses has to do with the magnitude of the 
problem it's trying to solve.  A widespread problem, frequently occurring, may 
justify harsher means than a theoretical issue that may or may not happen in 
the future.

> 
> > Asking for proof is not at all the same as denying it exists.
> > Not knowing that something exists, and even finding it difficult to believe 
> > it
> does - is not the same as knowing that it doesn't exist / denying it.
> 
> When one person says something happens, asking for proof may be
> reasonable and backup precisely what you say. However, that's not the case
> here. At least a dozen people have said "something happened".

I don't recall seeing more than a handful of people who said 'Something 
happened', but even if I grossly miscounted - we have to go back to the point I 
made above.  Due to the widespread confusion about what this is trying to fix, 
the fact that people are insisting that 'Something happened', does not at all 
mean they necessarily refer to things that this RFC is supposed to address.  
For instance, when a certain person says "We clearly have a problem", how can I 
know whether he refers to the 'toxic internals' problem, or a true 
violence/sexual harassment allegation?  Based on the fact I've seen more than a 
dozen people talking about how a CoC is about solving the 'toxic internals' 
problem, my educated guess is that most people that said that "there's a 
problem" meant the 'toxic internals' problem, and not safety issues.

That leads to another important issue.  We're a very global project.  Different 
cultures around the world have very different ideas regarding what's considered 
acceptable or even legal.  What may seem completely unreasonable to a 
'reasonable American',  may seem completely fine to the average 'reasonable 
German'.  What may seem completely reasonable to the 'reasonable Israeli', may 
look unacceptable to the 'reasonable Japanese'.  Sometimes, it's not just 
culture - but the law itself may view things very differently from one country 
to another (see 
en.wikipedia.org/wiki/Sexual_harassment#Varied_legal_guidelines_and_definitions 
for an 

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Pierre Joye]

On Thu, Jan 14, 2016 at 8:37 PM, Tom Worster  wrote:
> Hi Stas,
>
> Sorry for the follow up but I only noticed this after I woke up this
> morning.
>
> Amusing irony! In this instance, I tried to make a technical argument
> about language and you picked up the wrong end of the stick and blew up
> out of proportion because I didn't choose words that make clear me purpose.
>
> If I can get a smile out of Internals, I just gotta take it.
>
> That's all. I have to concentrate on other things today.
>
> Tom
>
>
> On 1/13/16, 6:46 PM, "Stanislav Malyshev"  wrote:
>
>>Hi!
>>
>>> Right now I can call out your last paragraph. But before I do, remember
>>> John's point about perception versus reality. I go further. With respect
>>> to what goes down on a list-serv, there is only perception and nothing
>>> else matters. The following characterizations may seem wrong to you but
>>>if
>>
>>I don't think it's right. This is basically claiming the right to deny
>>reality. Of course, each person has the right to be delusional, but if
>>we each operate on basis of our own delusions without basis in reality,
>>I don't see how collaboration would be possible.
>>
>>> wrong. But unless you did, "and still have no answer" is an accusation
>>>of
>>> me and/or John of being delinquent in answering it.
>>
>>No, it's not. It is trying to get us from venting bad feeling to looking
>>for solution - in which I failed miserably, evidently. You can build a
>>narrative of being offended and attacked out of anything, if you are
>>determined to do so. This, however, is an unproductive and
>>nonconstructive behavior, which will never find any solutions and
>>improve anything.
>>
>>I however would submit it presents an excellent example of the danger of
>>enforcing such vague and subtle things as "perception" and "atmosphere".
>>One can blow literally *anything* out of proportion and present it as an
>>attack and an insult, even if nothing like that was ever meant.
>>
>>> However, I am not sure this was your purpose. 1. thru 6. also suggest
>>>your
>>
>>My purpose was to start constructive process of producing ideas and
>>finding solutions, if there was a will to cooperate on that. So far my
>>impression is there's none. OK then, moving on to code fixes.
>>
>>--
>>Stas Malyshev
>>smalys...@gmail.com

I think we get every one point about where we stand, between the
people against a CoC, against a CoC with teeth etc. This is getting
nowhere and we are really off topic.

I would suggest to stop talking in circle for now and wait the next
version of the RFC. Then we can focus on the content of the CoC, let
me rephrase that, then we can focus only on the content of the CoC and
the eventual "CoC group" and its role.

Please.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Tom Worster]

Hi Stas,

Sorry for the follow up but I only noticed this after I woke up this
morning.

Amusing irony! In this instance, I tried to make a technical argument
about language and you picked up the wrong end of the stick and blew up
out of proportion because I didn't choose words that make clear me purpose.

If I can get a smile out of Internals, I just gotta take it.

That's all. I have to concentrate on other things today.

Tom


On 1/13/16, 6:46 PM, "Stanislav Malyshev"  wrote:

>Hi!
>
>> Right now I can call out your last paragraph. But before I do, remember
>> John's point about perception versus reality. I go further. With respect
>> to what goes down on a list-serv, there is only perception and nothing
>> else matters. The following characterizations may seem wrong to you but
>>if
>
>I don't think it's right. This is basically claiming the right to deny
>reality. Of course, each person has the right to be delusional, but if
>we each operate on basis of our own delusions without basis in reality,
>I don't see how collaboration would be possible.
>
>> wrong. But unless you did, "and still have no answer" is an accusation
>>of
>> me and/or John of being delinquent in answering it.
>
>No, it's not. It is trying to get us from venting bad feeling to looking
>for solution - in which I failed miserably, evidently. You can build a
>narrative of being offended and attacked out of anything, if you are
>determined to do so. This, however, is an unproductive and
>nonconstructive behavior, which will never find any solutions and
>improve anything.
>
>I however would submit it presents an excellent example of the danger of
>enforcing such vague and subtle things as "perception" and "atmosphere".
>One can blow literally *anything* out of proportion and present it as an
>attack and an insult, even if nothing like that was ever meant.
>
>> However, I am not sure this was your purpose. 1. thru 6. also suggest
>>your
>
>My purpose was to start constructive process of producing ideas and
>finding solutions, if there was a will to cooperate on that. So far my
>impression is there's none. OK then, moving on to code fixes.
>
>-- 
>Stas Malyshev
>smalys...@gmail.com



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Stig Bakken]

On Thu, Jan 14, 2016 at 1:18 PM, Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: Larry Garfield [mailto:la...@garfieldtech.com]
> > Sent: Wednesday, January 13, 2016 9:46 PM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines --
> > "let's proceed to ideas"
>
>
> > There's an important point we've been glossing over here that I think is
> > important to make explicit, as it is part of the reticence people have
> about
> > CoCs, "culture change", etc.  That all presupposes that there are
> problems,
> > which means that fixing them implies some people's behavior will need to
> > change.  People don't like needing to change their behavior (regardless
> of
> > whether that behavior is subjectively "good" or "bad").
>
> I view this a bit differently.
>
> First, I think saying something like "People will have to change" is not a
> good description of what we're after.  If we're going to declare something
> along the lines of 'New rules here, you're going to have to change' - then
> yes, I think we're going to have a very hard time - both in getting buy-in,
> and in terms of the likelihood of this whole thing actually resulting in
> transforming the atmosphere on internals for the better.  I also don't
> think we need to create unanimous agreement that 'there is a problem'.
> That's the wrong first step - as it creates controversy from the get go (as
> it already did).  The way I see it, we don't need to acknowledge having a
> problem in order to want to improve.  I'm sure that resonates with most
> developers on this list - wanting to continuously improve does not mean
> you're saying that things were problematic to begin with.  Instead, it's an
> assumption which is literally always true - wherever you are, whatever you
> do, you can always do better.  It's true for everything - processes,
> relationships, code - and mailing list etiquette.
>
> The right question, IMHO, is do we want to improve?  Do we want to try and
> be more polite and respectful?  Do we want to try and improve the
> atmosphere?  That's a much easier goal to rally around, I think, and for
> the most part, I can hardly imagine there won't be consensus around it.
>
> > Many lists I'm on, particularly those with high churn, send out an email
> every
> > month automatically with list rules et al.  98% of people won't bother
> reading
> > them 98% of the time, but for the first time you see it it's an
> indication of "oh,
> > yeah, they've code some expectations in place, maybe I'll read them" and
> for
> > subsequent times it's a reminder of "oh yeah, that thing, it exists."
> Similar
> > idea to the company (I forget
> > which) that has the company principles printed out in everyone's cube to
> > read over every morning.
>
> Something along the lines of this should be at least a part of the
> solution, I think.  Continuing the point I made above, instead of having a
> laundry list of what not to do - we should focus on the values and behavior
> we want to encourage  - positive expectations.  I wouldn't call them
> 'rules', either, but guidelines, such as Please Be Respectful, or 'Please
> don't do to others would you wouldn't want others to do to you'.  Humans
> tend to react negatively when they're forced to do something, and much
> better when they're encouraged to do it - especially as we don't want to go
> in the direction of sanctions.  If we end up having a mediation team (not
> the CR team, but a team whose pure job is to mediate) - I think it would be
> fair for it to jump in in case it sees a discussion going south or a
> certain person that's going against the spirit of these values - and I
> believe that in the vast majority of cases, it would be more than enough
> for them to cool off.  Ultimately I think most people want to improve.


I agree whole-heartedly with Zeev here!

Anyone who has a clue about organizational psychology will tell you to
focus on what you want more of, not on what you want to eliminate.  Heck,
anyone who is a parent today should understand this intuitively.

The main focus of a CoC should be positive, describing or even giving
examples of respectful behavior, that way people are guided towards
"wanted" behavior, instead of having to figure it out by process of
elimination from a list of what NOT to do.  Granted, there is such a thing
as common sense, but it's not always that common, so providing positive
guidance is effective.

Several people have suggested splitting the RFC into two: one for the CoC
itself (which should be easier to rally around), and another for how
to deal with problems.  I think this is a very rational approach, it allows
us to learn from experience with the CoC as formulated before setting up
any kind of tribunal or banning system which could backfire badly in
various ways.

 - Stig

RE: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Zeev Suraski]

> -Original Message-
> From: Tom Worster [mailto:f...@thefsb.org]
> Sent: Thursday, January 14, 2016 5:26 PM
> To: Pierre Joye 
> Cc: Stanislav Malyshev ; PHP internals
> 
> Subject: Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines --
> "let's proceed to ideas"
> 
> On 1/14/16, 9:37 AM, "Pierre Joye"  wrote:
> 
> >I think we get every one point about where we stand, between the people
> >against a CoC, against a CoC with teeth etc.
> 
> I wasn't talking about the Code of Conduct. Different topic.

Exactly my point re: 'widespread confusion'.

Zeev

Re: [PHP-DEV] RFC proposal for alternative list syntax

[Julian Rhind]

Hi


Thanks all for the feedback - I'm posting back to get some "RFC karma" for my 
newly created wiki account please - so I can post my RFC - username is "julian"


Thanks


Regards


Julian



From: Kris Craig 
Sent: 28 December 2015 18:40
To: Pierre Joye
Cc: PHP internals list; Julian Rhind; Stanislav Malyshev
Subject: Re: [PHP-DEV] RFC proposal for alternative list syntax


On Dec 27, 2015 7:56 PM, "Pierre Joye" 
> wrote:
>
> On Mon, Dec 28, 2015 at 6:20 AM, Stanislav Malyshev 
> > wrote:
> > Hi!
> >
> >> // With the new array syntax this has been improved to
> >>
> >> list ($a, $b) = [1, 2];
> >>
> >> // I think this new syntax should logically extend to
> >>
> >> [$a, $b] = [1, 2];
> >
> > list() and array() are two different language constructs, using the same
> > syntax for them is a bad idea.
>
> I tend to agree here but it exists elsewhere and is quite handy. Also
> the behavior of this expression, in this case, is obvious.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

This could be very nice shortcut to have.  Seems intuitive enough; I doubt 
there'd be any serious confusion over this.

You should draft an RFC for this, OP.

--Kris

Re: [PHP-DEV] Re: [RFC] Normalize token_get_all() output (with flag)

[Andrea Faulds]

Hi Sara,

Sara Golemon wrote:

How does this sound?
1. Keep the current RFC basically as is.  It's a minor addition to
token_get_all() which can be slotted into existing code to improve
readability, but offers little advantage beyond that.
2. Make a new extension to prototype this PhpToken class outside of
the php-src tree, add all the extra goodies we want (array of token
return, iterator of token return, extra info, limited info, etc...)
3. When this extension is good and solid, propose merging into core.

I had reserved the github.com/phplang project for the specification,
but didn't end up using it.  We can share a repo there if you'd like.


Like Stas, I think this sounds good. I might even look over what's 
created, if I find the time.


Regarding arrays versus iterators, you can create the former from the 
latter, but not the other way around. I'd go for just having an iterator 
and no array.. It maps better to how PHP actually works, anyway.


But enough discussion here, I shall await your git repository...

Thanks!
--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #68063

[Yasuo Ohgaki]

Hi Stas,

On Fri, Jan 15, 2016 at 4:32 AM, Stanislav Malyshev  wrote:
>
>> However, previous my fix (Raise warning and return false) was wrong fix.
>> Therefore, I would like to correct (Provide new session ID and continue)
>> it in 5.5 also. Does this make sense?
>
> Yes, but nit sure if it's for 5.5. It's for Julian to decide,
> ultimately, but it doesn't look like 5.5 has a security issue right now
> with it? Or am I wrong?

No. It does not have security bug, but has wrong fix for the security bug.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[David Zuelke]

On 14.01.2016, at 13:18, Zeev Suraski  wrote:

> The way I see it, we don't need to acknowledge having a problem in order to 
> want to improve.  I'm sure that resonates with most developers on this list - 
> wanting to continuously improve does not mean you're saying that things were 
> problematic to begin with.  Instead, it's an assumption which is literally 
> always true - wherever you are, whatever you do, you can always do better.  
> It's true for everything - processes, relationships, code - and mailing list 
> etiquette.
> 
> The right question, IMHO, is do we want to improve?  Do we want to try and be 
> more polite and respectful?  Do we want to try and improve the atmosphere?  
> That's a much easier goal to rally around, I think, and for the most part, I 
> can hardly imagine there won't be consensus around it. 

I really like this line of thinking, and the positivity it projects.

David



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #68063

[Yasuo Ohgaki]

Hi Julien,

On Fri, Jan 15, 2016 at 9:10 AM, Yasuo Ohgaki  wrote:
>
> On Fri, Jan 15, 2016 at 4:32 AM, Stanislav Malyshev  
> wrote:
>>
>>> However, previous my fix (Raise warning and return false) was wrong fix.
>>> Therefore, I would like to correct (Provide new session ID and continue)
>>> it in 5.5 also. Does this make sense?
>>
>> Yes, but nit sure if it's for 5.5. It's for Julian to decide,
>> ultimately, but it doesn't look like 5.5 has a security issue right now
>> with it? Or am I wrong?
>
> No. It does not have security bug, but has wrong fix for the security bug.

I'll commit the fix from PHP 5.6. If you think this should be included for
PHP 5.5, please cherry pick.  I prefer to have this in PHP 5.5, but it's
not mandatory.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #68063

[Stanislav Malyshev]

Hi!

> However, previous my fix (Raise warning and return false) was wrong fix.
> Therefore, I would like to correct (Provide new session ID and continue)
> it in 5.5 also. Does this make sense?

Yes, but nit sure if it's for 5.5. It's for Julian to decide,
ultimately, but it doesn't look like 5.5 has a security issue right now
with it? Or am I wrong?

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #71038 session_start() returns TRUE on failure

[Stanislav Malyshev]

Hi!

> I made PR
> https://github.com/php/php-src/pull/1721
> 
> for bug #71038
> https://bugs.php.net/bug.php?id=71038
> 
> Currently, the patch is written as it should and
> breaks compatibility on PHP 5.6.
> 
> To be compatible with PHP 5.6 (PHP 7.0 is OK),
> it may ignore read failures returned from save handlers.

I think it should return false on 5.6 too. The docs say:

This function returns TRUE if a session was successfully started,
otherwise FALSE.

Thus, if the session was *not* successfully started, it should return
false.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixing bug #71038 session_start() returns TRUE on failure

[Yasuo Ohgaki]

Hi Stas,

On Fri, Jan 15, 2016 at 4:05 PM, Stanislav Malyshev  wrote:
>> I made PR
>> https://github.com/php/php-src/pull/1721
>>
>> for bug #71038
>> https://bugs.php.net/bug.php?id=71038
>>
>> Currently, the patch is written as it should and
>> breaks compatibility on PHP 5.6.
>>
>> To be compatible with PHP 5.6 (PHP 7.0 is OK),
>> it may ignore read failures returned from save handlers.
>
> I think it should return false on 5.6 too. The docs say:
>
> This function returns TRUE if a session was successfully started,
> otherwise FALSE.
>
> Thus, if the session was *not* successfully started, it should return
> false.

In most cases other than read failure, PHP 5.6 is made return FALSE
for failures also.

Read failure is special because old save handler allowed returning false
for read and continued as if there is no errors. I cannot fix this without
braking buggy save handlers compatibility.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Number Format Separator

[Björn Larsson]

Den 2016-01-13 kl. 19:48, skrev Thomas Punt:

Hi internals!

Voting has opened for the inclusion of a digit separator in PHP[1]. Voting ends 
in
one week's time on January 20th.

Thanks,
Tom

[1]: http://wiki.php.net/rfc/number_format_separator


Well, if I had a vote it would definetly be +1. A small question
though, why is the voting period only one week (small RFC or)?

Regards //Björn Larsson


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php