Le 05/01/2016 10:51, Zeev Suraski a écrit :
the vote is now
open for the PHP 5 Support Timeline RFC:
https://wiki.php.net/rfc/php56timeline#vote
Hi,
We've discussed this at length at AFUP, and would be +1 to extend the
lifetime of PHP 5, by a huge margin.
As for the duration, we would be o
> On January 12, 2016 at 7:05 PM Adam Howard wrote:
>
> Can we please move on past this and get back to actual code. Because if
> not, perhaps PHP Internals has outgrown the email format and should migrate
> to a forum type format.
Agreed.
Sascha
--
PHP Internals - PHP Runtime Development Ma
> -Original Message-
> From: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Sent: Wednesday, January 13, 2016 3:11 AM
> To: Zeev Suraski ; John Bafford
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines
> (WAS: Adopt Code of Conduct)
>
> Hi!
>
Hi Stas,
On Wed, Jan 13, 2016 at 10:08 AM, Stanislav Malyshev
wrote:
>> The root cause is browser's cookie handling.
>> It appears that browsers do not lock cookie while updating cookies.
>> Therefore race condition happens and browsers send empty cookie
>> sometimes. I haven't checked the code,
Hi!
> I have one idea. I made an awful mistake while drafting the Voting
> RFC, requiring a 2/3 majority for language changes. It should have
> been 85-90%. When you have a 85-90% majority - it's likely to imply
> several things:
I have a feeling that wouldn't help. Instead of "it's toxic beca
Hi!
> The root cause is browser's cookie handling.
> It appears that browsers do not lock cookie while updating cookies.
> Therefore race condition happens and browsers send empty cookie
> sometimes. I haven't checked the code, but observed it happens.
>
> I observed handful empty cookies a day w
On Tue, Jan 12, 2016 at 3:26 PM, Stanislav Malyshev 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 e
Hi Stas,
On Wed, Jan 13, 2016 at 8:03 AM, Stanislav Malyshev wrote:
>> 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
On 1/12/16 5:27 PM, Zeev Suraski wrote:
4. As soon as authors notice substantial opposition, they'll quickly realize
they're dealing with an RFC that's very unlikely to pass, and probably eiter
abandon it or go back to the drawing board - and eliminate any contention
that may have otherwise surr
> 4. As soon as authors notice substantial opposition, they'll quickly realize
> they're dealing with an RFC that's very unlikely to pass, and probably eiter
> abandon it or go back to the drawing board - and eliminate any contention
> that may have otherwise surrounded it.
One other thing I forg
Hi!
> Nice! I'll say one thing though: If we're going to introduce a class,
> I'm tempted to leave token_get_all alone (or at least limit its
> changes to what's in the current porposal), and have the PhpToken
> class implement its own static method to do the same thing. This
I like this idea be
On Mon, 2016-01-11 at 22:46 -0500, John Bafford wrote:
> So let's say, hypothetically, internals actually, seriously, wants
> newcomers.
Back in the days when I was more active when teaching newcomers
internals in articles and conferences I typically pointed them to
pecl-dev for the first discus
John,
Thanks for taking the time to write that lengthy email.
There are a lot of things in there I agree with, and a lot I disagree with, but
that's beside the point for now.
One part in particular in your message got me thinking:
> I understand that we’re a passionate people, and that sometim
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
Hi!
> Let me reiterate that the question that was posed, and which I am
> answering is, “Why do people avoid internals?” and “Does internals
> want to attract newcomers?”
Sure, but you talked about specific behavior in specific discussion.
Except of an incident of some unfortunate name-calling, m
Hi Julien,
I've disallowed empty session ID, but it wasn't a
appropriate fix.
https://bugs.php.net/bug.php?id=68063
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
Hi all,
I've already written a blog on the topic, so needless to say I have no
objections personally to seeing a Code of Conduct. Reading the current
draft RFC, I did see a few potential issues which I'd like to raise on
the specific text used insofar as it's starting point.
1. It should probably
On Tue, Jan 12, 2016 at 5:00 PM, François Laupretre
wrote:
> Le 12/01/2016 15:52, Dan Ackroyd a écrit :
>
>> François Laupretre wrote:
>>
>> I would like the process to be amended to disable posting
>>> opinions/discussions about an RFC while the vote is open,
>>> considering there was enough tim
>
>
> We’ve got a giant steaming pile of crap here. As awesome as U+1F4A9 is,
> the fix is to stop trying to polish the turd and actually clean up our act.
> You want php-internals to lose its toxic reputation? Here’s how: *STOP
> BEING TOXIC*. How? I dunno. I’m open to ideas. I’m happy to help. Wa
On Tue, Jan 12, 2016 at 9:07 AM, Rouven Weßling wrote:
>> On 05 Jan 2016, at 21:52, Andrea Faulds wrote:
>> This is more of a side-note, but maybe it's worth bringing up. Since
>> token_get_all gives an array with subarrays of a regular structure, might it
>> be worthwhile returning an array of
Can we please move on past this and get back to actual code. Because if
not, perhaps PHP Internals has outgrown the email format and should migrate
to a forum type format.
On Tue, Jan 12, 2016 at 11:45 AM, Pierre Joye wrote:
> On Jan 12, 2016 11:17 PM, "Sascha Schumann" <
> sascha.schum...@myra
> On 05 Jan 2016, at 21:52, Andrea Faulds wrote:
>
> This is more of a side-note, but maybe it's worth bringing up. Since
> token_get_all gives an array with subarrays of a regular structure, might it
> be worthwhile returning an array of objects instead? It would probably reduce
> memory usa
Sascha,
> On Jan 12, 2016, at 11:17, Sascha Schumann
> wrote:
>
> Hi John,
>
>> And it is *not* acceptable.
>
> May I ask who put you in charge to determine whether something is "acceptable"
> or "reprehensible”?
*I* avoid internals because *I* believe the conduct here is reprehensible, and
On Jan 12, 2016 11:17 PM, "Sascha Schumann" <
sascha.schum...@myrasecurity.com> wrote:
>
> Hi John,
>
> > And it is *not* acceptable.
>
> May I ask who put you in charge to determine whether something is
"acceptable"
> or "reprehensible"?
(for him) and other.
Everyone speaks for himself or a smal
> -Original Message-
> From: Andreas Heigl [mailto:andr...@heigl.org]
> Sent: Tuesday, January 12, 2016 5:34 PM
> To: Zeev Suraski ; Eli
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
>
> Am 12.01.16 um 15:53 schrieb Zeev Suraski:
> >> Can we please
Hi John,
> And it is *not* acceptable.
May I ask who put you in charge to determine whether something is "acceptable"
or "reprehensible"?
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 12.01.16 um 16:45 schrieb Sascha Schumann:
>> During the CoC-Discussion the idea came up to vote certain CoC-issues
>> (call them whatever you like) in a more secure way so that no one sould
>> be able to bully someone into an - for him or her - inappropriate
>> decission. One way to do so could
Stas,
On Jan 11, 2016, at 23:24, Stanislav Malyshev wrote:
>
> Hi!
>
>> This is yet another example of the toxic internals problem.
>> Regardless of one's views on the CoC proposal, the conduct of
>> php-internals as a whole has been reprehensible.
>
> What in your opinion was reprehensive, co
Le 12/01/2016 15:52, Dan Ackroyd a écrit :
François Laupretre wrote:
I would like the process to be amended to disable posting
opinions/discussions about an RFC while the vote is open,
considering there was enough time for that during the
discussion phase.
This is not a good idea.
That won't
On 12 January 2016 at 15:27, Chase Peeler wrote:
> I personally offered at least two emails with constructive feedback and
> alternative solutions. I never saw any reply or feedback to either one.
It's not possible for every email to be replied to in a conversation.
If they were, then the convers
> My take away from Anthony's last email is basically: "We're going to have a
> CoC whether you like it or not. You are welcome to offer feedback to make
> the CoC better after we propose it, but any feedback that says a CoC is bad
> will be viewed as non-constructive and ignored."
That would be f
> During the CoC-Discussion the idea came up to vote certain CoC-issues
> (call them whatever you like) in a more secure way so that no one sould
> be able to bully someone into an - for him or her - inappropriate
> decission. One way to do so could be a somehow anonymised vote.
Is discussing thin
Am 12.01.16 um 15:53 schrieb Zeev Suraski:
>
>
>> -Original Message-
>> From: Andreas Heigl [mailto:andr...@heigl.org]
>> Sent: Tuesday, January 12, 2016 4:21 PM
>> To: Eli ; internals@lists.php.net
>> Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
>>
>> Am 12.01.16 um 15:06 schrieb
I personally offered at least two emails with constructive feedback and
alternative solutions. I never saw any reply or feedback to either one. I
also had some emails in which I was somewhat argumentative (the ones
related to the definition of harassment). I still stand by those emails as
they were
Peter Cowburn wrote:
> On 11 January 2016 at 12:14, Zeev Suraski wrote:
>
>> I have no idea if it's related, but is there any chance the patch caused
>> some older votes to be broken - at least in how they're displayed?
>> Case in point:
>> https://wiki.php.net/rfc/voting/vote
>
> The patch for
Am 12.01.16 um 15:56 schrieb Peter Petermann:
>>
>> Discussions happen. Then a vote is called, everyone votes instantly.
>> Yes, the votes do become public afterwards. However there is not the
>> '2-3 week period' of voting that happens on a PHP RFC, wherein you vote,
>> and then while the vote
Hi Christoph,
> echo 1_000;
> will print
> 1000
>
> I think it is important to explicitly note that in the RFC.
>
> With regard to "stringy numerics": besides the potential BC break, IMHO
> there is no need to support digit separators for string literals at all,
> because that could easily be prov
> -Original Message-
> From: Eli [mailto:e...@eliw.com]
> Sent: Tuesday, January 12, 2016 5:07 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
>
> On 1/12/16 9:53 AM, Zeev Suraski wrote:
> > I'm at least one of the people who talked with Eli regardi
On 1/12/16 9:53 AM, Zeev Suraski wrote:
> I'm at least one of the people who talked with Eli regarding the STH
> vote (the one for my RFC, not Eli's). It was a ~20 message DM exchange
> on Twitter, very respectful (Eli - if you think otherwise, please say
> so), and was truly aimed at understanding
>
> Discussions happen. Then a vote is called, everyone votes instantly.
> Yes, the votes do become public afterwards. However there is not the
> '2-3 week period' of voting that happens on a PHP RFC, wherein you vote,
> and then while the vote is still up, and while you are allowed to change
>
> -Original Message-
> From: Andreas Heigl [mailto:andr...@heigl.org]
> Sent: Tuesday, January 12, 2016 4:21 PM
> To: Eli ; internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki
>
> Am 12.01.16 um 15:06 schrieb Eli:
> > On 1/12/16 5:16 AM, Dennis Birkholz wrote:
>
François Laupretre wrote:
> I would like the process to be amended to disable posting
> opinions/discussions about an RFC while the vote is open,
> considering there was enough time for that during the
> discussion phase.
This is not a good idea.
That won't actually make people discuss a proposa
Am 12.01.16 um 15:06 schrieb Eli:
> On 1/12/16 5:16 AM, Dennis Birkholz wrote:
>> I don't think voting on an RFC is like electing your government. I
>> would compare it to how a House of Representatives works. And at least
>> here in Germany, they vote publicly except when electing people (e.g.
>>
Results for project PHP master, build date 2016-01-12 06:30:56+02:00
commit: 786d959
previous commit:e6ed53e
revision date: 2016-01-11 22:04:04+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 1/12/16 5:16 AM, Dennis Birkholz wrote:
> I don't think voting on an RFC is like electing your government. I
> would compare it to how a House of Representatives works. And at least
> here in Germany, they vote publicly except when electing people (e.g.
> the Chancellor).
That's a fine comparis
On 1/11/16 10:46 PM, John Bafford wrote:
Stop the nonsense. Get better, grow up, treat each other with respect, and act
like the adults you are. I'd like to work with you all, but you make it dammned
hard to want to.
Hi John,
Good for you for writing and sending your email! Really.
The natu
Thomas Punt wrote:
>> I'd like to propose for the inclusion of a digit separator in PHP. This will
>> help to promote the readability of numerical literals in code by enabling for
>> the underscore character to be used in between digits.
>>
>> RFC: https://wiki.php.net/rfc/number_format_separator
On Tue, 12 Jan 2016, Peter Petermann wrote:
> >
> >
> > > This seems useful. I do wonder whether we should use by default for
> > > RFCs. It's interesting to see how different people vote, and knowing
> > > who voted which way means you can ask them what their objections were.
> > I have gotten th
>
>
> > This seems useful. I do wonder whether we should use by default for
> > RFCs. It's interesting to see how different people vote, and knowing
> > who voted which way means you can ask them what their objections were.
> I have gotten these question in the past, and I think it's important to
>
> Hi internals!
>
> I'd like to propose for the inclusion of a digit separator in PHP. This will
> help to promote the readability of numerical literals in code by enabling for
> the underscore character to be used in between digits.
>
> RFC: https://wiki.php.net/rfc/number_format_separator
> PR: h
Giovanni Giacobbi wrote on 12/01/2016 09:37:
But the fact is that it did NOT exist, so when you say "other than the
specific transition to PHP 7", well I think it is a big deal and
motivates the introduction of a new feature just for that.
I guess what I meant was, once everyone has been using
giova...@giacobbi.net (Giovanni Giacobbi) wrote:
> Also think about the possible upcoming changes to the Throwable definition,
> I saw in another thread that you are thinking about dropping
> Throwable::getCode(), which would make things even worse, in case of
> something as simple as:
> set_excep
Hi Eli,
Am 11.01.2016 um 15:45 schrieb Eli:
On 1/10/16 8:15 AM, Dennis Birkholz wrote:
I would really like to understand the rational behind anonymous voting
in the PHP internals context. Votes for RFCs should be purely based on
technical reasons and whether the language change would benefit th
I want to thank Markus and Björn for getting me up to speed with the
pointers.
Please see the rest of my response below.
On 11 January 2016 at 15:05, Rowan Collins wrote:
> Giovanni Giacobbi wrote on 11/01/2016 13:31:
>
>> set_exception_handler(callback function, bool also_throwables = false);
>
On 12/01/16 04:24, Stanislav Malyshev wrote:
>> This is getting a bit ranty. But internals deserves it. You all may
>> > be great programmers, but in terms of making people *want* to work on
>> > php-src, you're shitty salespeople.
> Maybe. For myself, I'm pretty much surely a shitty salesperson. H
55 matches
Mail list logo
