Re: [PHP-DEV] Set SA_ONSTACK in zend_sigaction External

Hi Kevin, Master should be targeted, no RFC is required, and the patch looks fine to me. Cheers Joe On Thu, 22 Sep 2022, 14:56 Kévin Dunglas, wrote: > Hi, internals! > > It's been a while. > > I'm currently working on a new SAPI for web servers written in Go. > Many virtual machines,

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

Hi all, Applications are open for a week. Two people will be chosen by election and a veteran will help them. If no other veteran comes forward I will continue in that role for 8.2. Cheers Joe On Tue, 26 Apr 2022, 21:21 Eric Mann via internals, wrote: > I'm new to this mailing list as I'd

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

Morning internals, Today, some friends of the project, people we consider leaders even, are waking up in a war zone. They are living an unimaginable horror, and as I sit here and type, I fight back tears for them ... I am afraid for them, their families, their lives. The feeling of helplessness

Re: [PHP-DEV] Unbreak git.php.net links?

I didn't think about external links ... I guess then redirecting would be best. The nameserver configuration is still as it was (I think), so it's probably best to setup the NS to point at web and then someone can do the work in the web repo (I suppose). Cheers Joe On Mon, 4 Oct 2021 at 08:01,

Re: [PHP-DEV] Unbreak git.php.net links?

October 2021, Joe Watkins wrote: > This seems reasonable. > > I wonder if we could log the redirects so that we can obtain the list of > links and update accordingly so that we may eventually retire the domain > without breaking stuff. > > Cheers > Joe > > On Mon

Re: [PHP-DEV] Unbreak git.php.net links?

This seems reasonable. I wonder if we could log the redirects so that we can obtain the list of links and update accordingly so that we may eventually retire the domain without breaking stuff. Cheers Joe On Monday, 4 October 2021, Stanislav Malyshev wrote: > Hi! > > I know we're no longer

Re: [PHP-DEV] [VOTE] Nullable intersection types

and that degrades my confidence that making the change this late even if it does pass is a good idea. Cheers Joe On Mon, 16 Aug 2021 at 10:04, Nikita Popov wrote: > On Mon, Aug 16, 2021 at 9:45 AM Joe Watkins wrote: > >> Morning all, >> >> The initial RFC was clear that nulla

Re: [PHP-DEV] [VOTE] Nullable intersection types

Please rearrange and add words as necessary, so that they makes sense :) "... however that doesn't seem to have been widely understood". Cheers Joe On Monday, 16 August 2021, Joe Watkins wrote: > Morning all, > > The initial RFC was clear that nullability was not

Re: [PHP-DEV] [VOTE] Nullable intersection types

Morning all, The initial RFC was clear that nullability was not supported, however that doesn't seem to be have widely understood. When I said we should move forward I did imagine that there was some consensus about the syntax we should use if we were to support nullability. As this

Re: [PHP-DEV] Shut down gcov.php.net

+1, this was always the long term plan. Cheers Joe On Wednesday, 4 August 2021, Nikita Popov wrote: > On Wed, Aug 4, 2021 at 2:25 PM Christoph M. Becker > wrote: > > > Hi all, > > > > I suggest to shut down altogether. It is barely > > maintained for quite a while: PHP

Re: [PHP-DEV] [RFC] Nullable intersection types

This is not a new feature. This is a detail of a feature that was not well understood for whatever reason. That is why we are willing to fix it after freeze. I would ask anyone voting to vote on the basis of the detail and leave timing to be the problem of release managers. Voting negatively

Re: [PHP-DEV] intersection types and null for defaults, properties and return types

Agree, an RFC looks like the only way. This is not worth delaying a release for, nor is it worth postponing the feature freeze date. It seems reasonable to fix this after freeze, would prefer to reach consensus before RC stage. Cheers Joe On Tue, 20 Jul 2021 at 13:07, Nikita Popov wrote: >

[PHP-DEV] Re: Fake Closure Comparison

The test included is quite comprehensive. Cheers Joe On Friday, 9 July 2021, Larry Garfield wrote: > On Fri, Jul 9, 2021, at 4:51 AM, Nikita Popov wrote: > > On Fri, Jul 9, 2021 at 10:45 AM Joe Watkins wrote: > > > > > Morning internals, > > > > >

[PHP-DEV] Fake Closure Comparison

Morning internals, While discussing some of the details of the first class callable RFC, it became apparent that fake closures (created by Closure::fromCallable) are not currently comparable in a useful way. Although this is not directly related to the first class callable feature, it's likely

Re: [PHP-DEV] FFI Type Reflection API

Hi Dmitry, It doesn't make sense to wait another year for this, and since it's self contained it's fine to merge into 8.1 when ready. Cheers Joe On Wednesday, 7 July 2021, G. P. B. wrote: > On Wed, 7 Jul 2021 at 10:31, Dmitry Stogov wrote: > > > Hi, > > > > Last week, at a PHP conference, we

Re: [PHP-DEV] [RFC] [VOTE] is_literal

9 > > > > The proposal is to add the function is_literal(), a simple way to > identify > > if a string was written by a developer, removing the risk of a variable > > containing an Injection Vulnerability. > > > > This implementation is for literal strings ONLY

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

before this > one > > > > goes to a vote. > > > > > > Hi again. > > > > > > With PFA being declined, I've again reworked the Pipes RFC. > > > > > > 1) It now does not use PFA in any examples, but it does use Nikita's > >

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Please, stop spamming us with the same comments. Cheers Joe On Sat, 26 Jun 2021 at 14:25, Dan Ackroyd wrote: > On Fri, 25 Jun 2021 at 00:57, Craig Francis > wrote: > > > Dan Ackroyd wrote: > > > Please can you go into some detail about what you think people are > > > meant to do when they

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Nobody has demonstrated that "string" . int can lead to anything but mistakes. It CANNOT lead to injection, and that's what we're talking about, we're not talking about a function that protects you from all possible security concerns or bugs. The actual definition of injection matters, when we

Re: [PHP-DEV] [Vote] Partial Function Application

I'd like to note a couple of things ... The behaviour of nullsafe and strict types being unspecified in the RFC would allow us to solve those problems later. The behaviour of strict types right now is objectively wrong, the partial takes strictness from the application site, so as Nikita already

Re: [PHP-DEV] [RFC] is_literal

Refcounted* not recounted ... Predictive text on phone ... Cheers Joe On Friday, 18 June 2021, Joe Watkins wrote: > Just to explain this tracking of longs. > > We can track strings because there's space to do that in GC info which > recounted types all have. > > Where thing

Re: [PHP-DEV] [RFC] is_literal

Just to explain this tracking of longs. We can track strings because there's space to do that in GC info which recounted types all have. Where things aren't recounted there is no usable space on the value to store the literal flag without disabling some internal assumptions about type flags. We

Re: [PHP-DEV] Rename Fiber::this() to Fiber::getCurrent()

This doesn't look like the sort of detail we need to vote on. It would be nice if this were made in time for the migration guide and other doc to be prepared for 8.1. Let's move forward, please ... Cheers Joe On Tue, 15 Jun 2021 at 21:54, Larry Garfield wrote: > On Tue, Jun 15, 2021, at 2:01

Re: [PHP-DEV] [RFC] is_literal

15 Jun 2021 at 10:56, Claude Pache wrote: > > > Le 15 juin 2021 à 09:19, Joe Watkins a écrit : > > Morning, > > https://3v4l.org/nJhc1/rfc#focus=rfc.literals > > It's not so much a bug as a side effect or quirk. > > Note that, the result is correct, in the sense th

Re: [PHP-DEV] [RFC] is_literal

Morning, https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe. It's just that existing implementation details - RETURN_CHAR

Re: [PHP-DEV] [RFC] is_literal

Afternoon all, While this is not at all my idea, I wrote the patch, so my words may seem bias/hollow. Still, here are some words ... In the past this kind of feature would have been extremely invasive, it would have had so many edges because of the way we handled strings that it was never really

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

There's a couple of typos in the RFC, which Larry will fix when he has time. There was also a typo in patch, and a fault in patch. All fixed. pending tests, 3v4l won't update until tomorrow. Cheers Joe On Fri, 11 Jun 2021 at 13:02, Guilliam Xavier wrote: > Sorry, me again :s I have tested

Re: [PHP-DEV] Consensus Gathering: is_initialized

Thanks for all the input everyone, very successful consensus gathering exercise. Since the response was pretty overwhelmingly negative, I think we can just stop here. I've closed the PR and wrapped up the FR. Anyone is of course free to pursue the RFC that would be required, however ill

Re: [PHP-DEV] Consensus Gathering: is_initialized

uch talked myself out of it at this point already ... I'm hearing what I expected to hear. Cheers Joe On Wed, 26 May 2021 at 14:57, Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > > > śr., 26 maj 2021 o 12:14 Joe Watkins napisał(a): > >> Hi internals, >&

Re: [PHP-DEV] Consensus Gathering: is_initialized

helps you to decide if it's good or bad, but I'm particularly interested in your concrete answer to the question of badness. Cheers Joe On Wed, 26 May 2021 at 12:30, Marco Pivetta wrote: > > > On Wed, May 26, 2021 at 12:14 PM Joe Watkins wrote: > >> Hi internals, >> >&

[PHP-DEV] Consensus Gathering: is_initialized

Hi internals, In response to: https://bugs.php.net/bug.php?id=78480 I implemented: https://github.com/php/php-src/pull/7029 Not absolutely convinced that it's a good idea, I asked Nikita to review, and he's unconvinced also and suggested a discussion should be started. You can read both of our

[PHP-DEV] Pear SSL Cert Expired

Can someone fix it please ? Cheers Joe

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

Morning, Still I think heavy use has to be the exception, especially heavy use where readline is not available (because it's questionably useful). Cheers Joe On Wed, 12 May 2021 at 11:39, Pierre wrote: > Le 12/05/2021 à 11:29, Joe Watkins a écrit : > > Morning Nikita, > > >

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

Morning Nikita, +1 on the change to cli. It can't really be a default extension right now because readline license is not compatible: https://github.com/php/php-src/pull/3823 Even without the license problem, I'm not convinced of the value of adding the dependency: Because of this long

Re: [PHP-DEV] Re: Bugsnet

Hi all, I shouldn't have said we can "just" move ... I'm not supposing it will be easy. We can "just move", in about the same sense that we can "just move" today. Considering the difficulty of problems we do not currently have is a waste of time. Cheers Joe On Sun, 9 May 2021 at 10:08,

[PHP-DEV] Re: Bugsnet

Hi Stas, I did mention that we're leaving aside the sec issue for now. > Let me list all it is lacking that we have right now, with current old and dusty bugs: 1)

[PHP-DEV] Bugsnet

Morning internals, We have a spam problem on bugsnet, it's not a new problem. Nikita had to waste time deleting 20 odd messages from bugsnet yesterday and this is a common, daily occurrence. We clearly don't have time for this. Quite aside from spam problems, bugsnet is hidden away in a dark

Re: [PHP-DEV] [RFC] Property accessors

I haven't read it properly yet (been watching a little), but I just wanted to say thanks for the refreshing honesty :) Cheers Joe On Tue, 4 May 2021 at 12:34, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: >

Re: [PHP-DEV] Retire distributions repo in favor of something more suitable

of the protection that version files used to have. It's not so simple ... Cheers Joe On Wed, 28 Apr 2021 at 16:18, Joe Watkins wrote: > That's a good point. > > I suppose the most we can do is prevent accidental committing of such > things. > > Appears to be two "solutions" ... &

Re: [PHP-DEV] Retire distributions repo in favor of something more suitable

That's a good point. I suppose the most we can do is prevent accidental committing of such things. Appears to be two "solutions" ... We could distribute a pre-commit hook, which is somewhere between "not bad", and "pretty awkward" if your git installation is old. We could setup one of the

Re: [PHP-DEV] Retire distributions repo in favor of something more suitable

Morning all, I'd be very up for that ... The "alternative workflow" in this document seems reasonable for us to use (or modify for use): https://wiki.debian.org/Creating%20signed%20GitHub%20releases RE vendor lock-in: Any provider we may move to in the future is going to have to be based on

Re: [PHP-DEV] wiki.php.net upgrade

seems ok. > > Can we test it in the production environment, but not yet release it? > > [1] https://github.com/php/web-wiki/pull/15 > > — > wbr, > Sergey Panteleev > > > From: Joe Watkins > Date: Thursday, 8 April 2021, 11:23 > To: Stanislav Malyshev &

Re: [PHP-DEV] wiki.php.net upgrade

Any use case we have for content or collaboration is best served by whomever or whatever is going to secure that content or ability to collaborate. Nobody has updated the wiki in several years, despite warnings, and two very public breaches of security that we know about. We don't have the

[PHP-DEV] PHP 8.1 Release Manager Selection

Afternoon all, I have decided to volunteer to mentor the 8.1 release managers as a veteran release manager. We have many volunteers from the community for this release, and intend to hold a vote to choose two of them to be mentored by myself. Expect more communication to follow, some slight

Re: [PHP-DEV] Improving output of syntax errors

Nicely done. No need for an RFC. Thanks. On Sunday, 28 June 2020, Stanislav Malyshev wrote: > Hi! > > > For more examples, see: > > https://rwec.co.uk/x/php-parse-errors/comparison.html > > > > The patch can be reviewed at: https://github.com/php/php-src/pull/5722 > > I think this is great,

Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas

I just want it to be noted that I requested that the decision is reconsidered also. I think, plain and simple, a mistake has been made. Cheers Joe On Wed, 15 Jan 2020 at 10:40, Pierre Joye wrote: > On Tue, Jan 14, 2020, 8:08 PM Peter Cowburn wrote: > > > On Tue, 14 Jan 2020 at 12:27, Nicolas

[PHP-DEV] Extension: ilimit

Hi all, I intend to publish (or have someone else publish) https://github.com/krakjoe/ilimit to pecl in the coming days, any comments/objections/other relevant noises ? Cheers Joe

Re: [PHP-DEV] GitHub RFC workflow

ake a whole lot of practical sense. If we can't find practical reasons not to take advantage of what is being offered, then I don't think we should put theoretical problems in the way of progress. Cheers Joe On Mon, 4 Nov 2019 at 12:57, Pierre Joye wrote: > > > On Mon, Nov 4, 2019,

Re: [PHP-DEV] GitHub RFC workflow

pen source project. I'm also not suggesting we move everything to github. I'm simply questioning the "owning all content" mantra because it doesn't make as much sense today as perhaps it once did. Cheers Joe On Mon, 4 Nov 2019 at 08:19, Pierre Joye wrote: > > > On Mon, Nov

[PHP-DEV] Re: FFI & Security

:41, Christoph M. Becker wrote: > On 14.10.2019 at 09:44, Joe Watkins wrote: > > > Recently we voted on classification criteria for security bugs [1], we > > include under "not an issue" any issue that "requires invocation of > > specific code, which may be valid bu

Re: [PHP-DEV] GitHub RFC workflow

Morning, I don't want to follow this tangent for too long on owning content. Pierre, can you point to any contribution that would have been blocked by our use of github ? For all intents and purposes, the majority of new development does actually happen on github. As a result of us being

Re: [PHP-DEV] GitHub RFC workflow

Evening Nikita, This is not really what we imagined when we started to discuss using github for pull requests - everything is going to end up on the wiki anyway. I do think this is a very reasonable first step, given how the discussion went on github and given the general feeling that we ought

[PHP-DEV] PHP 7.1.33 Released

The PHP development team announces the immediate availability of PHP 7.1.33. This is a security release. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.33 please visit our downloads page. Windows binaries can be found on the PHP for Windows site. The

Re: [PHP-DEV] Computing code coverage on Azure Pipelines

I am current maintainer of gcov server, I planned this kind of integration with azure, so once again, thanks. +1 to ditching gcov.php.net, we are terrible at infra ... On Mon, 14 Oct 2019, 16:13 Nikita Popov, wrote: > On Mon, Sep 30, 2019 at 2:30 PM Gerard Roche > wrote: > > > > gcov.php.net

[PHP-DEV] FFI & Security

Morning all, Recently we voted on classification criteria for security bugs [1], we include under "not an issue" any issue that "requires invocation of specific code, which may be valid but is obviously malicious". I would like to add an explicit clause under the "not an issue" section for

Re: [PHP-DEV] Defining the PHP Group

utor needs to recognize. I'm not going to discuss the legalities of what it means that the group hold copyright, you and I are not lawyers and that conversation is meaningless. Cheers Joe On Mon, 16 Sep 2019 at 11:35, Pierre Joye wrote: > Hi Joe, > > On Mon, Sep 16, 2019 at 4:25 PM

Re: [PHP-DEV] Defining the PHP Group

Pierre, I repeat, there are no vetos, for anyone. Cheers Joe On Mon, 16 Sep 2019 at 11:04, Pierre Joye wrote: > On Mon, Sep 16, 2019 at 4:01 PM Pierre Joye wrote: > > > > On Mon, Sep 16, 2019 at 3:49 PM Joe Watkins wrote: > > > > > > Hi Pierre, > > &

Re: [PHP-DEV] Defining the PHP Group

Hi Pierre, > The RFC process defines a veto and could be applied when needed. Can you show me where that is defined please ? Cheers Joe On Mon, 16 Sep 2019 at 10:36, Peter Bowyer wrote: > On Sun, 15 Sep 2019 at 14:16, Zeev Suraski wrote: > > > > How can an undefined group have copyright

Re: [PHP-DEV] Defining the PHP Group

Stas, > Not can't, shouldn't be. And I don't see any reason why we should stop saying that. Because it's a waste of everyone's time. The RFC process is the only one we have. > RFC process was not created to be sole governing body for PHP project and something that makes every vote mandatory for

Re: [PHP-DEV] Defining the PHP Group

t; > Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins : > > > > Morning internals, > > > > There is confusion among the community, and contained in the documented > > history of PHP on the wider internet. > > > > The Wikipedia states that PHP is

[PHP-DEV] Defining the PHP Group

Morning internals, There is confusion among the community, and contained in the documented history of PHP on the wider internet. The Wikipedia states that PHP is developed by the PHP Group, in saying this it is (must be) referring to internals as a whole, but our own documentation names members

Re: [PHP-DEV] Changing fundamental language behaviors

I'm finished communicating with you. Cheers Joe On Fri, 13 Sep 2019 at 01:45, Zeev Suraski wrote: > > > On 13 Sep 2019, at 2:21, Joe Watkins wrote: > > Zeev, > > I'm going to keep this really short and simple ... > > > I'll do the same. > > You don't have the

Re: [PHP-DEV] Changing fundamental language behaviors

Zeev, I'm going to keep this really short and simple ... You don't have the authority to make unilateral decisions for PHP,. Nothing you are saying is going to have any effect, the people who actually work on the language will merge whatever is voted in. Cheers On Fri, 13 Sep 2019, 00:17 Mike

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

> Because the PHP project should avoid depending on a privately owned centralized service for its technical discussions This is obviously your opinion, but you haven't actually told us why this is the case, and it's not at all obvious. > should not encourage (some would say force) people to use

Re: [PHP-DEV] Remove special Zend karma

+1 Cheers Joe On Fri, 23 Aug 2019 at 10:33, Nikita Popov wrote: > Hi internals, > > We currently have separate karma for the Zend/TSRM directories in php-src. > I think this separation has become more annoying than useful at this point. > Most changes from newer contributors are approved on

Re: [PHP-DEV] Removing old branches in php-src

We already have a git repository where we keep historical branches, we don't need to create another. I'm really not sure what the problem is here, and we have spent far too long discussing this non issue. Cheers Joe On Mon, 19 Aug 2019 at 23:23, Olumide Samson wrote: > > > > Maybe it might

Re: [PHP-DEV] Re: Implement lzma (xz?) compression (was Req #63880)

Note, while reading the code I noticed it doing some odd things with strings (see casting away constness in patch) ... this wants a maintainer, I was just getting the build going [and not volunteering] ... Cheers Joe PS. Sorry about double post ... On Mon, 19 Aug 2019 at 15:42, Joe Watkins

Re: [PHP-DEV] Re: Implement lzma (xz?) compression (was Req #63880)

Afternoon, Patch for php7: https://gist.github.com/krakjoe/549ec38161ecd1ad9b8f16f6cf18657e Run with it, or not ... Cheers Joe On Mon, 19 Aug 2019 at 14:43, Christoph M. Becker wrote: > Hi! > > On 19.08.2019 at 12:47, Tobias Frei wrote: > > > Today I was asked to contact this list about the

Re: [PHP-DEV] Removing old branches in php-src

I saw the list and the ages, what I didn't see was a justification for removing them. I think a proper analysis hasn't really been performed, for example the native-tls branch was merged after ng into the 7.0 series, and I didn't remove it because it serves as a reference point for the old vs the

Re: [PHP-DEV] Removing old branches in php-src

Morning, I pretty much just echo what Sara said, I'm not sure what harm they are doing ... Cheers Joe On Mon, 19 Aug 2019 at 04:09, Sara Golemon wrote: > On Sun, Aug 18, 2019 at 6:06 PM G. P. B. wrote: > > > It seems this topic already has been raised a year ago [1] but nothing > has > >

[PHP-DEV] Preliminary Polling

Morning internals, I've got a sort of fuzzy idea to make provisions in the RFC process for preliminary polling. It seems there are several situations where a preliminary poll makes sense, it would have made sense for the p++ discussion and saved us a week of wasted time. It also makes sense when

Re: [PHP-DEV] Bringing Peace to the Galaxy

*alongside patch Cheers Joe On Fri, 9 Aug 2019, 09:33 Kris Craig, wrote: > On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote: > > > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote: > > > > > > > > > > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov > > wrote: > > > > > >> This is

Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

Morning all, First, I want to say that I don't think the polarisation claimed to be occurring is actually occurring. The vast majority of internals voters appear to judge each RFC on it's own merit, while some of them give more weight to retaining bc than others and that effects their vote, they

[PHP-DEV] PHP 7.1.31 Released

Hi, The PHP development team announces the immediate availability of PHP 7.1.31. This is a security release which also contains several minor bug fixes. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.31 please visit our downloads page. Windows

Re: [PHP-DEV] [RFC] Strict operators directive

Evening, There doesn't seem to be a patch or implementation. Aside from the proposed semantics, which I can't really read because the document is malformed, the most important questions for me are: How is this going to work? Can it be done without significant complexity in the compiler or VM?

Re: [PHP-DEV] [RFC] Deprecations for 7.4

Just a note on process. It is not necessary to hold multiple RFC's: > For procedural reasons, multiple RFCs may be combined into one, in which case there may be multiple primary votes. > Combining multiple RFCs into one does not allow turning a primary vote into a secondary vote. In general,

Re: [PHP-DEV] [RFC] [Vote] Base convert changes

It will likely be easier if the Allow negative numbers implementation (targetting master only) is entirely separate from the Error on ignored characters implementation,. Cheers Joe On Wed, 19 Jun 2019 at 09:56, Joe Watkins wrote: > There should probably be a PR targeting

Re: [PHP-DEV] [RFC] [Vote] Base convert changes

easier for 2 prs ? one for each vote ? > > Thanks > > Scott > > > On 19.06.2019 08:31, Joe Watkins wrote: > > The implementation of this does not look ready, there are conflicts > > so I can't test it locally, but last time CI ran there were many > > failures. &g

Re: [PHP-DEV] [RFC] [Vote] Base convert changes

The implementation of this does not look ready, there are conflicts so I can't test it locally, but last time CI ran there were many failures. Cheers Joe On Wed, 19 Jun 2019 at 09:24, Scott Dutton wrote: > Hi all > > I have put my RFC base convert changes to vote this morning > >

Re: [PHP-DEV] Re: [PATCH] Add configuration value to enable/disable stack tracelogging

Evening all, I've prepared an alternative: https://github.com/php/php-src/pull/4282 Hiding the arguments seems sensible enough, not as a hardcoded default (default behaviour should be retained), but as a documented recommended default for production. I think, this needs to go through the RFC

Re: [PHP-DEV] Pre-Announcing Feature Freeze @ July 22nd, 2019

Just for clarity, I think the next version will be 8, right? Cheers Joe On Fri, 14 Jun 2019, 16:22 Derick Rethans, wrote: > Dear Internallers, > > With 7.4.0alpha1 having been released yesterday, the feature freeze for > PHP 7.4 is coming up fast. > > Feature Freeze is *Monday July 22nd,

Re: [PHP-DEV] [RFC] Unbundle ext/recode

Hi Christoph, I'm not even certain this needs to be put to a vote ... we should not be shipping that. +1 whatever ... If you can't find a single dissenting voice, just get rid of the thing before the next alpha, or possibly the first beta/rc ... Cheers Joe On Fri, 14 Jun 2019 at 14:27,

[PHP-DEV] Re: commit 374f76998 causes getenv to be define with Xdebug loaded

anks. Dmitry. > ------ > *From:* Joe Watkins > *Sent:* Wednesday, June 12, 2019 9:38:54 PM > *To:* Derick Rethans > *Cc:* Dmitry Stogov; PHP Developers Mailing List > *Subject:* Re: commit 374f76998 causes getenv to be define with Xdebug > loaded > > Hi all, > > My

[PHP-DEV] Re: commit 374f76998 causes getenv to be define with Xdebug loaded

Hi all, My clumsy ass reverted that in PHP-7.4, totally and utterly by accident, and since it resolved Dericks problem, I went ahead and reverted in master also rather than make maybe unnecessary noise. Very very sorry about that, I totally intended to get Dmitry's approval/opinion. Terrible

Re: [PHP-DEV] Using [ci skip]

Cowburn wrote: > > > On Fri, 7 Jun 2019 at 12:09, Joe Watkins wrote: > >> Oh to be absolutely clear, I'm talking about commits that *only* touch >> these non-source files ... >> >> Cheers >> Joe >> >> On Fri, 7 Jun 2019 at 13:07, Joe Watkins

Re: [PHP-DEV] Using [ci skip]

Oh to be absolutely clear, I'm talking about commits that *only* touch these non-source files ... Cheers Joe On Fri, 7 Jun 2019 at 13:07, Joe Watkins wrote: > Hi Marco, > > It wasn't a topic for discussion, it was a request to committers in > php-src. > > We do not need

Re: [PHP-DEV] Using [ci skip]

> 2. You never know what can break, that's why it's "continuous" there > (besides religious views around what "continuous integration" means) > > On Fri, Jun 7, 2019, 12:51 Joe Watkins wrote: > > > Hi all, > > > > Just a friendly reminder that

[PHP-DEV] Using [ci skip]

Hi all, Just a friendly reminder that when we're committing changes to files that do not contain source, test code, or build configuration, it's helpful to include [ci skip] in the commit message. Omitting it can put our CI quite far behind. Cheers Joe

[PHP-DEV] Azure DevOps Organization

Morning all, Nikita and I have finished setting up Azure Pipelines now: We have a 4 build configuration, which tests PHP in all permutations of Release/Debug ZTS/NTS Opcache/NoOpcache/JIT. Because of the way I've set it up, my name is in the url, so this morning I went to create a PHP

[PHP-DEV] CI with Azure Pipelines

Evening internals, PHP-7.4 and master have been setup to run CI on Azure, Azure having much more resources than Travis, we can run tests in all permutations of Debug/Release, NTS/ZTS, with and without opcache, and with JIT. It's possible to setup mac/windows on Azure, although myself and Nikita

[PHP-DEV] Wiki display problem

I think this may be related to the ssl issues from earlier today, may have been overlooked ? Cheers Joe

[PHP-DEV] PHP 7.1.30 Released

Evening, The PHP development team would like to announce the immediate availability of PHP 7.1.30. This is a security release and all PHP 7.1 users are encouraged to upgrade. For source downloads of PHP 7.1.30 please visit our downloads page. Windows binaries can be found on the PHP for Windows

[PHP-DEV] MODERATE spam

Hi all, Does anyone know what is the cause of all the spam from the announce mailing list? I'm not sure who is getting it, but I'm getting a few emails a minute sometimes, it's rather annoying ... Can someone do some magic, and make it go away please ? Cheers Joe

Re: [PHP-DEV] open_basedir?

Morning Nikita, It would be wise to do a) and b) regardless of whether it's going to be removed. I think +1 on removing it in 8 ... I'm not sure if it should be deprecated in 7.4 first, or how that would work ? Cheers Joe On Tue, 7 May 2019 at 12:11, Nikita Popov wrote: > Hi internals, > >

[PHP-DEV] [RFC] Accepted: Abolish Short Votes

Morning internals, The abolish short votes RFC has been accepted and the Voting document updated. Cheers Joe

Re: [PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase

Hi Kalle, You forgot to move to voting on the RFC index. Cheers Joe On Tue, 9 Apr 2019, 19:07 Kalle Sommer Nielsen, wrote: > Den tir. 9. apr. 2019 kl. 20.02 skrev Kalle Sommer Nielsen >: > > > > Evening Internals > > > > Apologies for the one day delay, but the voting for the RFC "Unbundle >

[PHP-DEV] [RFC][Vote] Abolish Short Votes

Afternoon internals, Abolish Short Votes is now in voting: https://wiki.php.net/rfc/abolish-short-votes Cheers Joe

[PHP-DEV] PHP 7.1.28 Released

The PHP development team announces the immediate availability of PHP 7.1.28. This is a security release. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.28 please visit our downloads page. Windows binaries can be found on the PHP for Windows site. The

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

Thanks for explain. Cheers Joe On Wed, 3 Apr 2019 at 14:40, Rowan Collins wrote: > On Wed, 3 Apr 2019 at 13:33, Benjamin Morel > wrote: > > > PHP_FLOAT_MIN (float) > > > Smallest representable POSITIVE floating point number. If you need the > > > smallest representable floating point number,

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

2.2250738585072E-308 This is negative. Cheers Joe On Wed, 3 Apr 2019 at 12:27, Diogo Neves wrote: > It really don't make much sense: > > > var_dump( PHP_FLOAT_MIN < 0 ); > var_dump( PHP_INT_MIN < 0 ); > > On Wed, Apr 3, 2019 at 10:52 AM Benjamin Morel > wrote: > > > Hi internals, > > > > I

  1   2   3   4   5   6   >