On Tue, May 7, 2019 at 1:11 PM Nikita Popov wrote:
> Hi internals,
>
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
That's true, but only if it's in use. That's kind of fair...
> 2. Many people think
On Wed, May 1, 2019 at 3:19 AM Peter Kokot wrote:
> On Wed, 1 May 2019 at 00:56, Stanislav Malyshev
> wrote:
> >
> > Hi!
> >
> > > Worth noting another inconsistency here that we've missed. PHP 7.4 has
> > > introduced many BC breaks actually already. Without this level of
> > > problems:
> >
>
On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans wrote:
> On Mon, 29 Apr 2019, Zeev Suraski wrote:
>
> > On Sun, Apr 28, 2019 at 11:32 PM G. P. B.
> wrote:
> >
> > > I think this just boils down to what is an acceptable majority, if
> > > 2/3 is not eno
On Tue, Apr 30, 2019 at 7:03 PM Levi Morrison wrote:
> On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski wrote:
> >
> > On Tue, Apr 30, 2019 at 2:14 PM G. P. B.
> wrote:
> >
> > > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski wrote:
> > >
> >
On Tue, Apr 30, 2019 at 2:14 PM G. P. B. wrote:
> On Mon, 29 Apr 2019 at 16:53, Zeev Suraski wrote:
>
>> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd
>> wrote:
>> > Please stop doing this.
>>
>> I will gladly do so, once the project starts behaving re
On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd wrote:
> On Mon, 29 Apr 2019 at 13:29, Zeev Suraski wrote:
> >
> > If we go in this direction, though, then unless George agrees to withdraw
> >this RFC
>
> Zeev,
>
> I do not think you behaviour is appropriate
On Mon, Apr 29, 2019 at 5:26 PM Zeev Suraski wrote:
>
> ... wholesale compatibility break-fast ...
>
* break-fest
On Mon, Apr 29, 2019 at 11:17 AM Nikita Popov wrote:
>
> Keep in mind that for example the FFI RFC passed with something like 60%
> majority, even lower than this RFC. I think you're cherry-picking a bit
> here, when it comes to what should and shouldn't pass ;)
>
You're right, but I think that'
On Mon, Apr 29, 2019 at 10:55 AM Nikita Popov wrote:
> On Mon, Apr 29, 2019 at 9:34 AM Zeev Suraski wrote:
>
> >
> >
> > On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov
> > wrote:
> >
> >> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand
> w
On Sun, Apr 28, 2019 at 11:32 PM G. P. B. wrote:
> On Sun, 28 Apr 2019 at 14:36, Zeev Suraski wrote:
>
>> As I said numerous times in the past, I'm a firm believer that
>>>> controversial RFCs (ones that generate a lot of votes with a substantial
>>>>
On Thu, Apr 25, 2019 at 12:52 PM Nikita Popov wrote:
> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand wrote:
>
> > Hey,
> >
> > I feel like concatenation having the same precedence than addition and
> > subtraction is promoting programmers to make mistakes. Albeit typically
> > easy to catch ones,
On Sun, Apr 28, 2019 at 2:27 PM G. P. B. wrote:
> On Sun, 28 Apr 2019 at 10:01, Zeev Suraski wrote:
>
>> On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis wrote:
>>
>> > Also imo the reason why people write now (and not in the discussion
>> > phase) becau
On Wed, Apr 24, 2019 at 9:08 PM Reinis Rozitis wrote:
> Also imo the reason why people write now (and not in the discussion
> phase) because for some time in the voting there wasn't the 2/3 majority
> for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> votes make the diff
On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov wrote:
> Hi internals,
>
> I think it is well known that == in PHP is a pretty big footgun. It doesn't
> have to be. I think that type juggling comparisons in a language like PHP
> have some merit, it's just that the particular semantics of == in PHP m
On Thu, Feb 14, 2019 at 7:57 PM Larry Garfield
wrote:
> Data point: At Platform.sh (web host), we've been running ZTS builds of
> 7.1,
> 7.2, and 7.3 exclusively for a while now. We don't even offer non-ZTS
> versions of those releases.
I presume you haven't been using a threaded Web server mo
On Thu, Feb 14, 2019 at 7:27 PM Levi Morrison wrote:
> To all internals, but especially to Zeev and Dmitry,
>
> Having a JIT which does not support ZTS is a bit short-sighted.
I don't think anybody's advocating for not having ZTS support for JIT. I
am questioning the portof the absence of ZTS
On Thu, Feb 14, 2019 at 6:13 PM Joe Watkins wrote:
> EXACTLY
>
> Sorry I didn't answer in full, but I've been listening to people say its
> not important for so long, I'm pretty tired of it by now.
>
Joe, all,
Again, ISAPI was super important until one day, it wasn't. If the main
reason ZTS is
On Thu, Feb 14, 2019 at 5:59 PM Rowan Collins
wrote:
> All that being said, it would be nice if ZTS became more mainstream, so
> more people had access to userland threading / parallel processing
> extensions.
I think the most promising parallel processing paradigms today are based on
asynchron
On Thu, Feb 14, 2019 at 5:47 PM Christoph M. Becker
wrote:
> On 14.02.2019 at 12:56, Zeev Suraski wrote:
>
> > On Wed, Feb 13, 2019 at 11:26 AM Joe Watkins wrote:
> >
> >> The ZTS build is very commonly used in Windows today
> >
> > Any idea why?
>
>
On Thu, Feb 14, 2019 at 5:22 PM Rowan Collins
wrote:
> On Thu, 14 Feb 2019 at 11:57, Zeev Suraski wrote:
>
> > On Wed, Feb 13, 2019 at 11:26 AM Joe Watkins wrote:
> >
> > > The ZTS build is very commonly used in Windows today
> > >
> >
> >
On Wed, Feb 13, 2019 at 11:26 AM Joe Watkins wrote:
> The ZTS build is very commonly used in Windows today
>
Any idea why?
Zeev
On Thu, Feb 14, 2019 at 12:17 PM Rowan Collins
wrote:
> On Thu, 14 Feb 2019 at 09:43, Zeev Suraski wrote:
>
>> Does it mean that when PHP 8.0 comes out (in roughly two years' time most
>> probably), we'd be saying this is experimental? Or that only in the
>>
On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov wrote:
> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski wrote:
>
> > On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann
> > wrote:
> >
> > > Am 31.01.2019 um 18:08 schrieb Derick Rethans:
> > > > I
On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann
wrote:
> Am 31.01.2019 um 18:08 schrieb Derick Rethans:
> > I do not believe that something major like this should make it into any
> > PHP 7.x release. Having it as experimental new feature in the master/PHP
> > 8.0 branch makes the most sense
On Fri, Feb 8, 2019 at 2:18 AM Pierre Joye wrote:
> Hi Zeev,
>
> On Thu, Feb 7, 2019, 4:55 PM Zeev Suraski
>> All,
>>
>> I've read the detailed and very informative feedback from both Pierre and
>> Dan, as well as feedback from others (Nikita & mo
> -Original Message-
> From: Joe Watkins
> Sent: Friday, February 8, 2019 10:51 AM
> To: PHP internals
> Subject: [PHP-DEV] VOTE abolish narrow margins
>
> Morning all,
>
> As promised, abolish narrow margins is now open for voting:
>
> https://wiki.php.net/rfc/abolish-narrow-margin
On Thu, Feb 7, 2019 at 10:42 AM Pierre Joye wrote:
> On Thu, Feb 7, 2019 at 3:39 PM Zeev Suraski wrote:
>
> > It has to do with the relative power
> > of the code contributors, vs. folks who aren't code contributors who
> > presently have a vote even though the
All,
I've read the detailed and very informative feedback from both Pierre and
Dan, as well as feedback from others (Nikita & more) over the last few
days, and I'm now convinced that breaking the Voting part away from the
Workflow part is the right way forward. Not because ideally they shouldn't
On Wed, Feb 6, 2019 at 9:06 PM Niklas Keller wrote:
> > I'll reiterate my main two issues with this RFC:
> > - I do think that we need 50%+1 votes for certain decisions. Naming the
> > next version of PHP, or even deciding to release it outside of the yearly
> > cycle should not require a 2/3 vo
On Fri, Feb 1, 2019 at 1:38 PM Nikita Popov wrote:
> On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev
> wrote:
>
>> Hi!
>>
>> > Let me reply to the last point first, because I think that's really the
>> > crux here: The issue is not that this RFC is very urgent per se, it's
>> that
>> > it has
On Wed, Feb 6, 2019 at 10:50 AM Nikita Popov wrote:
> More importantly, while our past RFCs in the area of "packaging" have not
> been particularly major, that's isn't a property inherent to the category.
> For example, a proposal to introduce regular LTS releases, or to make other
> major change
On Tue, Feb 5, 2019 at 7:19 PM Nikita Popov wrote:
> On Tue, Feb 5, 2019 at 5:55 PM Zeev Suraski wrote:
>
>> On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov wrote:
>>
>>> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov
>>> wrote:
>>>
>>>
>
On Tue, Feb 5, 2019 at 5:17 PM Nikita Popov wrote:
> On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov
> wrote:
>
>
> I'd like to move forward with this change. I think the overall reception
> here has been positive, although in the discussion some other possibilities
> that avoid/reduce the BC aspe
On Tue, Feb 5, 2019 at 6:02 PM Côme Chilliet wrote:
> Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit :
> > We'll have to agree to disagree on this one. I would say that the way
> > virtually every other major Open Source project serves as a fairly good
&g
On Tue, Feb 5, 2019 at 12:09 PM Andrey Andreev wrote:
> Hi again,
>
> On Tue, Feb 5, 2019 at 10:37 AM Zeev Suraski wrote:
> >
> > Regardless of what you did, actually obtaining full voting rights
> > meant you had to ask for a VCS account, and have a reasonably good
On Tue, Feb 5, 2019 at 11:07 AM Côme Chilliet wrote:
> Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit :
> > Regardless of what you did, actually obtaining full voting rights
> > meant you had to ask for a VCS account, and have a reasonably good
> > explanatio
On Mon, Feb 4, 2019 at 10:56 AM Stanislav Malyshev
wrote:
> Hi!
>
> Reading the RFC, here's my thoughts:
>
Thanks for the detailed response!
> 1. Do we really need different classification of changes? I think having
> one single vote procedure would have larger benefit, and RFC that fails
> 2/
> -Original Message-
> From: Andrey Andreev
> Sent: Tuesday, February 5, 2019 5:18 AM
> To: Zeev Suraski
> Cc: Dan Ackroyd ; PHP internals
>
> Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
>
> You keep saying that, but it hasn'
> -Original Message-
> From: Dan Ackroyd
> Sent: Sunday, February 3, 2019 10:24 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
>
> On Sun, 3 Feb 2019 at 06:19, Zeev Suraski wrote:
> >
>
On Mon, Feb 4, 2019 at 12:33 PM Andrea Faulds wrote:
> A concern I have with the current RFC is a lack of a good case for why
> it should be necessary;
While this is a subjective opinion, it's definitely a valid one. Unlike
phpng (PHP 7) which was a slam dunk - JIT isn't - and whether or not t
On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov wrote:
> Hi internals,
>
> I would like to suggest that installation of PEAR is disabled by default in
> PHP 7.4. PR: https://github.com/php/php-src/pull/3781
This thread went a bit off topic, but to return to its original subject -
I'm also supportiv
On Sun, Feb 3, 2019 at 12:08 PM Nikita Popov wrote:
>
>> Personally, I find any proposal that does not deal with clearly defining
>> voting eligibility not only questionable, but a non-starter, that has no
>> parallels in any other major Open Source projects.
>>
>
> Why? While I think the questio
> On 3 Feb 2019, at 16:43, Jan Ehrhardt wrote:
>
> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>>
>>
>> How is that related?
>
> It is directly related with your statement that "developers with other
> host OSs still use Linux fo
On 3 Feb 2019, at 12:47, Jan Ehrhardt
mailto:php...@ehrhardt.nl>> wrote:
Hi Zeev,
Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
2. Most PHP production workloads are on Linux, and as far as I can tell
this trend is only growing over the years - with virtual machines a
On 1 Feb 2019, at 18:30, Larry Garfield
mailto:la...@garfieldtech.com>> wrote:
I'm... not sure how that answers my question? I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?" Or is that a situatio
> On 3 Feb 2019, at 7:17, Ben Ramsey wrote:
>
>> On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote:
>> I'm honestly a bit perplexed by how many people here viewing Windows
>> support as a must have, while at the same time I think we all agree PHP is
>> very s
On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd wrote:
> On Thu, 31 Jan 2019 at 13:44, Zeev Suraski wrote:
> >
> > Without further ado, an RFC that’s attempting to comprehensively solve
> many of the issues that have plagued our RFC process since it was hastily
> introduced
> -Original Message-
> From: Nikita Popov
> Sent: Saturday, February 2, 2019 6:24 PM
> To: PHP internals
> Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
>
> Hi internals,
>
> After discussing the topic with a number of current and former contributors, I
>
On Thu, Jan 31, 2019 at 7:00 PM Nikita Popov wrote:
> Let me reply to the last point first, because I think that's really the
> crux here: The issue is not that this RFC is very urgent per se, it's that
> it has already been delayed numerous times and it is imperative that we
> prevent that from
On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen wrote:
> Without my usual Windows bias, I do believe it is a considerable fact
> like Nikita pointed out as Windows is a first class citizen in terms
> of operating systems we support. While PHP on Windows may not have the
> speed that the Unix
On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen wrote:
> Hi Zeev
>
> Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> >
> > Without further ado, an RFC that’s attempting to comprehensively solve
> many of the issues that have plagued our RFC process since it
On Thu, Jan 31, 2019 at 5:56 PM Joe Watkins wrote:
> When I refer to "you", I really mean you and Dmitry, while you don't have
> a hive mind, you do act as one, or for one another in a lot of cases. If
> I'm wrong about that, I apologise.
>
You are wrong, apology accepted.
> > I would say that
On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov wrote:
> The fact that FFI may leak, is because it uses "unmanaged memory" (like
> in real C). PHP reference counting and GC just can't handle all the
> cases. It's impossible to automatically know what to do with C pointer,
> when we get it from func
On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov wrote:
> I agree with Joe here that we should handle the question of voting margins
> separately. Your RFC is a much more comprehensive reform, which contains a
> number of points that look highly controversial to me (such as the eligible
> voter chang
On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins wrote:
> Afternoon Zeev,
>
> I'm going to use unambiguous and direct language to make sure my intentions
> and concerns are communicated clearly, you can either receive this as a
> personal attack, or as a contributor being direct, I would prefer the
>
On Thu, Jan 31, 2019 at 3:53 PM Kris Craig wrote:
> I think you may be over-reaching a bit on the eligible voters part. Keep
> in mind that all those who would be affected would still be able to vote on
> this RFC. I think it's too restrictive on that part.
>
I realized that this part of the R
Without further ado, an RFC that’s attempting to comprehensively solve many of
the issues that have plagued our RFC process since it was hastily introduced in
2011:
https://wiki.php.net/rfc/voting2019
Emphasis on ‘attempting’. I’m sure there are still a lot of holes in it that
should be
PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins
Afternoon Zeev,
I imagine you will not like what I have to say either: In light of the recent
actions you have taken and are taking to push incomplete software into php-src
on narrow margins
>-Original Message-
>From: Joe Watkins
>Sent: Thursday, January 31, 2019 2:59 PM
>To: internals@lists.php.net
>Subject: [PHP-DEV] RFC Abolish Narrow Margins
>
>Afternoon internals,
>
>Some time ago I brought up for discussion:
>https://wiki.php.net/rfc/abolish-narrow-margins
>
>I intend t
> Okay, let's change it to "(c) The PHP Group" then. While that doesn't make it
> right, it does remove my main annoyance.
Done for master and the 7.4 branch. Thoughts on other versions?
Zeev
No, this case cannot be made. You are likely mixing up licensing and copyright
here. Licensing (in the absence of a CLA) follows the inbound=outbound
principle, i.e., it is understood that inbound contributions are made under the
same terms as the outbound license. However (in the absence of a
> I would like to make two changes to this header:
>
> 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of
> updating this for
> new major versions. I don't think the version information here is
> particularly useful to
> anybody.
I don't mind that much, but I don't see any
From: Levi Morrison
Sent: Monday, January 28, 2019 5:20 PM
To: Legale.legale
Cc: Nikita Popov ; PHP internals
Subject: Re: [PHP-DEV] Simplify license headers
> I have modified various files but don't think my name is on any of them. When
> ought it be there? Isn't git better at tracking that a
Sent from my mobile
On 15 Jan 2019, at 15:29, Christoph M. Becker
mailto:cmbecke...@gmx.de>> wrote:
On 15.01.2019 at 13:32, Zeev Suraski wrote:
On 15 Jan 2019, at 13:13, Christoph M. Becker
mailto:cmbecke...@gmx.de>> wrote:
Most recently, a pull request has been submitted
> On 15 Jan 2019, at 13:13, Christoph M. Becker wrote:
>
> Hi!
>
> Most recently, a pull request has been submitted for libgd[1], which
> suggests to define image IO functions for several image formats
> unconditionally; if the format is not supported, the IO functions would
> fail with an er
On Thu, Jan 3, 2019 at 3:30 PM Rowan Collins
wrote:
> On Thu, 3 Jan 2019 at 09:21, Zeev Suraski wrote:
>
> >
> > I agree, but the real question is how many of those who are explicitly
> > calling setlocale() are relying on this behavior
> >
>
>
> It occu
On Wed, Jan 2, 2019 at 8:57 PM Nikita Popov wrote:
> What I mean is that there are not many people who use float to string
> conversion with the express intention of receiving a locale-dependent
> result (and use a locale where the question is relevant). Those are the
> only people who would be (
On Wed, Jan 2, 2019 at 6:11 PM Nikita Popov wrote:
> On Wed, Jan 2, 2019 at 12:33 PM Zeev Suraski wrote:
> I don't expect this to be a particularly large issue for two reasons:
>
> 1. Not many people use this. I'm sure that there *are* people who use this
> and use i
On Wed, 2 Jan 2019 at 17:12 Christoph M. Becker wrote:
> On 02.01.2019 at 12:32, Zeev Suraski wrote:
>
> > Unless I'm missing something, changing this behavior would require a
> full,
> > line-by-line audit of the code - with no Search & Replace patterns that
>
On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov wrote:
> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev
> wrote:
>
> We have a rather hard policy against ini options that influence language
> behavior. Locale-dependent language behavior is essentially the same issue,
> just worse due to the men
On Mon, Dec 3, 2018 at 12:51 AM Andrea Faulds wrote:
> Hi Nikita,
>
> Nikita Popov wrote:
> > When the silencing operator @ is used, the intention is generally to
> > silence expected warnings or notices. However, it currently also silences
> > fatal errors. As fatal errors also abort request exe
On Sun, Nov 25, 2018 at 6:04 PM Sara Golemon wrote:
> On Sat, Nov 24, 2018 at 11:03 PM Marco Pivetta wrote:
>
> > Adding to the pile of "it's an edge case", since the preload scripts will
> > be procedural, wouldn't it be sufficient to call
> > `opcache_invalidate(__FILE__)` at the end of them?
On Sun, Nov 25, 2018 at 11:43 PM Marco Pivetta wrote:
> Is that space rrreally a problem?
>
> Take the example ZF loader from the RFC: that barely makes any difference
> at all.
>
> A stronger reasoning for another language construct (that changes engine
> behaviour) is kinfa required.
>
On Sun, Nov 25, 2018 at 7:03 AM Marco Pivetta wrote:
> Adding to the pile of "it's an edge case", since the preload scripts will
> be procedural, wouldn't it be sufficient to call
> `opcache_invalidate(__FILE__)` at the end of them?
>
> That would actually not do anything useful - as the file wil
On Sat, Nov 24, 2018 at 1:18 AM Rowan Collins
wrote:
> On 23 November 2018 12:48:40 GMT+00:00, Dmitry Stogov
> wrote:
> >Especially, the main preload.php, usually should be marked, to disable
> >its caching.
>
> Sorry, could you explain for those of us in the peanut gallery why this is
> the cas
On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker
wrote:
> On 15.11.2018 at 15:27, Nikita Popov wrote:
>
> > Based on previous discussions, it appears that our current plan is to
> > release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
> > they reach beta stage, which means
On Tue, Jul 17, 2018 at 9:02 PM Nikita Popov wrote:
>
> Sure, we can wait another week. Unless the additional discussion results in
> major changes to the RFC, we'll start voting next Monday (2018-07-23). In
> the interest of avoiding further delays, please try to view this as a hard
> deadline:
On 17 Jul 2018, at 21:02, Nikita Popov
mailto:nikita@gmail.com>> wrote:
On Tue, Jul 17, 2018 at 12:10 AM, Zeev Suraski
mailto:z...@zend.com>> wrote:
> Based on the feedback we received, we have decided to target PHP 7.4 for this
> RFC. A main factor for this decisio
On Tue, Jul 17, 2018 at 7:57 PM Nikita Popov wrote:
>
> Ah yes, *of course* the generated files will be part of distribution
> tarballs, just like we do with all generated files (not just the parser,
> but also configure.) While I forgot to write this in my original mail, it
> has been mentioned
On Tue, Jul 17, 2018 at 6:05 PM Nikita Popov wrote:
> I feel like we are all really in violent agreement that these files should
> be dropped from git, and at this point I'm not even sure what the
> discussion is about anymore. Let's wait until after PHP-7.3 branching in
> two weeks and drop them
On Tue, Jul 17, 2018 at 2:01 PM Sara Golemon wrote:
> On Tue, Jul 17, 2018 at 1:04 AM, Remi Collet
> wrote:
> > Le 13/07/2018 à 23:48, Zeev Suraski a écrit :
> > Perhaps we can also add all the generated files (including configure) in
> > the tagged versions, so the ta
> On 17 Jul 2018, at 7:12, Levi Morrison wrote:
>
> Fixing `array_slice` would probably do more harm than good at this
> stage. Instead I would like to provide an alternative function that
> does not have all this baggage, and will have decent performance much
> of the time. The best ideas I ha
> Based on the feedback we received, we have decided to target PHP 7.4 for this
> RFC. A main factor for this decision was that the RFC requires some
> non-trivial
> changes to 3rd-party extensions for full compatibility. This would put the
> ongoing (but nearly complete) effort to port extensions
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Friday, July 13, 2018 12:26 PM
> To: Dmitry Stogov
> Cc: PHP internals list ; Stanislav Malyshev
> ; der...@derickrethans.nl; Christoph M. Becker
>
> Subject: Re: [PHP-DEV] re2c version(s)
>
> On Fri, Jul 1
On Thu, Jul 12, 2018 at 7:38 AM Joe Watkins wrote:
> Zeev,
>
> > I think our voting rules are in need of a much thorough review than just
> pushing the limit to 2/3 - which also IMHO doesn't tackle the difference
> scenarios that exist out there.
>
> Agree, they need reform, but rather than tryin
> -Original Message-
> From: Joe Watkins [mailto:krak...@php.net]
> Sent: Wednesday, July 11, 2018 7:41 PM
> To: PHP internals
> Subject: [PHP-DEV] [RFC] abolish narrow margins
>
> Afternoon internals,
>
> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote in
> th
On Wed, Jul 11, 2018 at 5:44 PM Levi Morrison wrote:
> > It is being rushed as far as the RFC process & discussions around it are
> concerned - that's what I meant.
>
> I do not agree with this either. This has been previously discussed,
> they have given it an ample discussion period, and it see
On Wed, Jul 11, 2018 at 4:44 PM Levi Morrison wrote:
> > My logic is quite simple:
> > 1. Something as big as Typed Properties shouldn't be a last minute,
> rushed
> > RFC. Really - any RFC shouldn't - but in particular major language
> changes.
>
> I have seen this sentiment expressed elsewher
On Tue, Jul 10, 2018 at 10:19 PM Larry Garfield
wrote:
> While the marketing angle is valid, Zeev, it seems predicated on the idea
> that
> there won't be any other major new-and-cool features developed between now
> and
> 8.0. I'm reasonably confident that someone will find some user-facing
> e
On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalhães wrote:
> On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski wrote:
>
>> I've also given several examples - some of them arguably quite bigger than
>> this proposal - where we sat on code for a very long time (multiple years
>
On Tue, Jul 10, 2018 at 1:22 PM Nicolas Grekas
wrote:
> 2018-07-10 11:18 GMT+02:00 Marco Pivetta :
>
> > It's been a few weeks since this has first landed here, and we're just
> > wasting time in relatively silly discussions at this point:
> >
> > - As I said earlier, this patch has already been
an to force words into
your mouth.
Zeev
-Original Message-
From: Zeev Suraski [mailto:vsura...@gmail.com]
Sent: Tuesday, July 10, 2018 11:05 AM
To: Nikita Popov
Cc: Sara Golemon ; Christoph M. Becker ;
Kalle Sommer Nielsen ; Internals
Subject: Re: [PHP-DEV] [RFC] Deprecations for PH
On Tue, Jul 10, 2018 at 10:36 AM Nikita Popov wrote:
> On Tue, Jul 10, 2018 at 8:16 AM, Zeev Suraski wrote:
>
>>
>>
>> > -Original Message-
>> > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
>> > Golemon
>> > S
> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Monday, July 9, 2018 5:41 PM
> To: Christoph M. Becker
> Cc: Nikita Popov ; Kalle Sommer Nielsen
> ; Internals
> Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
>
> On Sun
> -Original Message-
> From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Friday, July 6, 2018 10:36 PM
> To: Christoph M. Becker
> Cc: Nikita Popov ; s...@php.net; Björn Larsson
> ; Dan Ackroyd ;
> Stanislav Malyshev ; Marco Pivetta
> ; PHP internals
> S
> -Original Message-
> From: Christoph M. Becker [mailto:cmbecke...@gmx.de]
> Sent: Wednesday, July 4, 2018 8:00 PM
> To: Zeev Suraski ; Nikita Popov
> Cc: Stanislav Malyshev ; Internals
>
> Subject: Re: [PHP-DEV] [RFC] Deprecate and remove case-insensitive constan
On Wed, Jul 4, 2018 at 5:12 PM Nikita Popov wrote:
> On Mon, Jun 25, 2018 at 8:03 AM, Stanislav Malyshev
> wrote:
>
>
> Are there any other opinions on this topic or the RFC in general? I'm a bit
> surprised that there are so little comments after the somewhat explosive
> discussion last time ar
On Wed, Jul 4, 2018 at 5:15 PM Nikita Popov wrote:
> On Wed, Jun 27, 2018 at 11:07 PM, Stanislav Malyshev
> wrote:
>
> > Hi!
> >
> > > In the proposal, the code is valid in all versions of PHP up to and
> > > including 7.3, *and represents the same algorithm in all versions*. The
> > > only diff
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Tuesday, June 26, 2018 9:28 PM
> To: Stanislav Malyshev
> Cc: PHP internals
> Subject: Re: [PHP-DEV] [RFC] Deprecate and remove continue targeting switch
>
> This RFC resolves the following issue:
>
> a) In
Sorry for top posting, but should we be discussing these at this point? If
these are targeting 7.4, I think we probably want to focus on the ones slated
to 7.3 at this point.
Perhaps we can add some further blurb (maybe in a box) that despite the RFC
acronym, at this point this is just a list
101 - 200 of 1400 matches
Mail list logo
