[PHP-DEV] PHP 7.1.17 Released

[Joe Watkins]

Evening,

The PHP team announces the release of PHP 7.1.17, a security release. All
users of PHP 7.1 are encouraged to upgrade.

Changes can be found: http://php.net/ChangeLog-7.php#7.1.17

Downloads are available: https://secure.php.net/downloads.php#v7.1.17

Verification information follows:

php-7.1.17.tar.bz2

-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJa33pzAAoJEPm6Ctoxy9iePqEH/iCVdMTYIR0fCuIQTTwXyPiB
IiyMeGwkMRrYKICqHINCzoqtwmB30JhgTem7a614q0avbpz3XheFObTrxhbmuHkD
TPM7kx4Ks2fNO9IOBLl7zLtlKfw3+rErIvGb8OCnLne8oNhyd7TE8ocLzenVL9Sk
GtfFO7dxf+cHjJsXBw0jBFM2pk1ahPqDmETutRlQIZs6Rzkdv33zWNTtKOKAFt5O
nVIuxv5+kbkAGVzBrv00M1/CBgiT5E5Xme3ObSI4KqoGZnBXIBER3/oyDBExsf6i
8zZ88Ns076d2jH85aHJzdjnIUqozASvkqjrPEJwnyyGN93zUfbiIAE1N1W9TUyQ=
=XpHI
-END PGP SIGNATURE-

php-7.1.17.tar.gz

-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJa33p1AAoJEPm6Ctoxy9iev/EH/RKM2bNYOV32zH3Wn2zD9iJu
QgXUWpo+6dJ3lz1fv5QpgYa2BB5SevNr1fRZtAZ9UhUTL/Skj0LpZY3bvsPoOL/8
JlBEpWmkuGQ9CbW/wbf3WPHKeKo8Im58eZcO2Kf+R6Yr+QexOp0dy5qPMSU34VMy
bqSRyC/5HJkzMRT2yZUBIiervLJ23w0ASJ6eQQxsK7TKHdNGM5n1zwcoTbFy7Lss
h9P1F4LmEHGFHrWH4t2dol3CGC40j+kEJZV7caEqEp2qY9UGG5yLuuEYBf+ve/Bp
/owk5twoweDOxaA9BiZLbiWUNMZvgQX+YLhXuESzF6frU78gAzKmSDfSakjZ91c=
=ejiQ
-END PGP SIGNATURE-

php-7.1.17.tar.xz

-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJa33p3AAoJEPm6Ctoxy9ied80IAK8BcMwrQDQ3Q9lei7/r2Vlc
1z4zvTHu+/W5KIyYVbs9Q3a4gl0RBwCyq2mdfPJzALeGv0urGYfs3YJw+g5UVzs/
2pqOoq82ZvMCvb1jNS65IdekvofjPHZHATHLkKWkn7QQHeNeepHWI5rnRka+NPOt
ZVEA4afMcoeXbUWCaQvrLoN6qwLnhRh1Miyl26hI4bKmXZblkf/EZ+Y+fdobJG3w
txaIXSALYTZd4SXRF40XFvZ0224KkvK1rDCgkL/RmzQiInr+FQ01nuHrneiMvD3T
CLjDbC39i1RCmFFnftIW85UjSNHyHxKQz/DOor8IqaTofF5vZF1w9UtquULwJ58=
=UCi6
-END PGP SIGNATURE-

Cheers
Joe

[PHP-DEV] PHP 7.1.15RC1 ready for testing

[Joe Watkins]

Evening all,

PHP 7.1.15RC1 is available for testing, downloads are at:

https://downloads.php.net/~ab

Please note, downloads are not in the normal location, and php-web may not
have updated just yet: I have a very poor internet connection and had to
call on the help of comrades to get this done.

Follows is verification information (tars are signed by me, as normal):

php-7.1.15RC1.tar.bz2
SHA256 hash:
db898ed849db819181e9dfdb7b82750a496bf40e64d6657077e3cf464996a568
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJagz4qAAoJEPm6Ctoxy9ie78YH/jpTYZiHNz+hlsU9BbcmAdhj
hedl6jcnTqseQbx/zN2ablRVrwzFyLM0ax31QiPc+0NgVgguWdsMB5/stpTvZeZ6
CDWnPgu1ENqzdDuQf6BGywq6D+5jLbcGK8Eox3EACV7xHRaXudeFpQ78ps/WzcMp
XqLvpmVRqp7VeFNbxZ/6ujxHGAlniKKA5APJsdMYWQcD4dSPV6lRd2Y+Kn2FS5qc
esQ4XO7l4pxr3HOD5sRt21dw3z9c/LEogiymh7bz0cjJEWCqCyMjCNMiSFnuDwWt
9eKaIXKMMmJdjeyXwxxPUKNFXT0/e5xusuEO3VcnnHe4xQ0woEjf/MEaqmQyHIs=
=f2AW
-END PGP SIGNATURE-


php-7.1.15RC1.tar.gz
SHA256 hash:
1590014036c9a957ec00f7166f11ad0042133b72fe7c474dbc862dca971275b6
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJagz4sAAoJEPm6Ctoxy9iexWIH/R7Ee5pTSc+R5YWco32FR3mF
2ZdJookAslQWkkNvOC6UB3k0xWCNwcEmQ/vnudVL4+1ENOeVoB7reS7Cz2pO0Y/M
ohoOW8UlgVH8xif/7F8LQ7GSJoDNdt+612XuB2Ft0GYK5A8cDob2S7/JO+iZWR8g
WqRqJSqkNIeFsKEV6ju5SSKrffubmqyHby2ptyHzcHz3OoZEsHU5/gJggIvul5ot
yH4fkIh0PZfiYA7vFWEu3/2OQAS2swwFyP72fDCcuhh6vTvY9IVM6Q5D082dkJjN
f+y+RCWO+J6bm+jnoVxL8GmD13dAMZV0lmzHXF/JYz2Ih5QRX+0+2WapsAwcqP8=
=GAO9
-END PGP SIGNATURE-


php-7.1.15RC1.tar.xz
SHA256 hash:
9d6198178ed5ef17a4d5657aca39274e5a68756e25928ab3581f5238ab780497
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJagz4sAAoJEPm6Ctoxy9iemGkH/1KbIofAFT2AmrwgEPN33O2x
+rSWbdDyMORxDNpYK9+TgtQi93EoX9M856HHwzJg0HiYNCc9hBaBFxXGC5XMRpro
ldh6GCITFqekw5TFWJFEqKzvctRP6j/BLBTcaHv3mHUuCTmOYn8vaLgsWW55LzPH
fnLgIQST9NTPp3jLZwYAIZLEZPPzxoGm4QNcwieisa7kHPxvjtWbXqlYa9h3APNz
fDShmmBTG5rr5Y4YjUd5ub6xBqKJVrOCTN1akHOBH9Lh3M4MmB5+gL15k00HsgFO
QW8cC6nz33b0jr/li1HocZpZB4x85L2o4VumxbC/93Eg9IWOreFWCmRs5azFKmk=
=yr/i
-END PGP SIGNATURE-

Cheers
Joe

Re: [PHP-DEV] Mailing list moderation

[Joe Watkins]

+1

It's true that everyone can setup their own filters, but why should they
have too.

You don't get to conduct yourself however you want without consequence.

Cheers
Joe

On Wed, Jan 3, 2018 at 6:52 PM, Rowan Collins 
wrote:

> On 3 January 2018 at 17:28, Chase Peeler  wrote:
>
> > I think self moderation still solves this. If the person is disruptive
> > enough, eventually enough people will block them and there won't be many
> > instances of them getting quoted or poisoning the thread.
> >
> > If certain people decide to engage them, then others will start to block
> > them as well.
>
>
>
> That all sounds like a lot of wasted effort. If we're not careful,
> endorsing that behaviour would end up with people sharing mail filter
> definitions, proxying the list through a shared filter, or just setting up
> a rival discussion forum. All of which just distract us further from making
> PHP better.
>
>
>
> > Maybe, maybe not. Either way, I don't want you making that decision for
> > me.  I should be allowed to determine at which point someone's negative
> > contributions outweigh their positive ones to a point that I no longer
> feel
> > they are productive.
> >
>
>
> I think maybe we have a different view of what a list like this is. To me,
> it's a forum where we're collaborating to a common aim; it has an existence
> in its own right, and we collectively shape that existence. I may be
> misunderstanding, but it sounds like you view it more as a public space
> where you can find individuals to communicate with, and you retain the
> right to shape those communications. Does that sound a reasonable
> characterisation? I'm not seeking to criticise, only to understand where
> this idea of "making the decision for me" comes from, because to me,
> moderation doesn't seem like a personal decision which is being taken away.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Mailing list moderation

[Joe Watkins]

The precedent has been set already: One of these users was already kicked
off the list and decided to resubscribe and continue to conduct themselves
in an unacceptable manner.

This is a forum for technical discussion regarding the development of PHP:
We must be able to keep conversation focused and one of the tools we have
to do that is restricting who is able to post. It seems perfectly
reasonable to exercise that power in order to improve the quality of
conversation and keep it focused.

Banning or suspending these users, and anyone else incapable of conducting
themselves reasonably, will serve that purpose.

Let's remember that there are a large number of people on the sidelines
that are not subscribed to the list directly, but choose to use news
readers, or the excellent externals.io; They may not able to filter
messages from any individuals, so they are in effect forced to navigate
through these "contributions" from problematic posters. That's not fair to
them, at all. All of the conversations here are a matter of public record,
not only existing in your mail client, or inbox, or whatever ... We can and
should be eliminating noise from that public record.

Cheers
Joe



On Wed, Jan 3, 2018 at 7:45 PM, Paul Jones <pmjone...@gmail.com> wrote:

>
> > On Jan 3, 2018, at 12:35, Joe Watkins <pthre...@pthreads.org> wrote:
> >
> > You don't get to conduct yourself however you want without consequence.
>
> Sure. The question then, is, what is the proper consequence? I hold that
> it is not "banning" or "suspension" (which may or may not actually be
> within the delegated powers of anyone on this list). Instead, it is "to be
> ignored, by those who choose to ignore you."
>
>
> --
> Paul M. Jones
> pmjone...@gmail.com
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>

[PHP-DEV] PHP 7.1.21RC1 is available for testing

[Joe Watkins]

Afternoon all,

PHP 7.1.21RC1 is available for testing and can be downloaded from
https://downloads.php.net/~ab

Windows binaries can be found at http://windows.php.net/qa/

Follows is verification information:

php-7.1.21RC1.tar.bz2
SHA256 hash:
e4febdcb3793cc78fb0512242a9b6a67fd32053c34c663d704f89b203148a5c8
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJbYcFuAAoJEPm6Ctoxy9ie5b0H/RfNFE+jcprDVYJtLf8xtY/I
LDYnZszQsgsmXWKJDF2uA0fMwHnV1IlmpW+O4LKuOZZdYm6vFUsN6QA4PlxvXCAh
GXt9DiDTLr1qaxf1HnozvQBqkD04+Vi/Wmd1ogAB4yRxa7Ti0QeE/iICbFgaXvAr
0sOMvgMcT74jEnl1a05I2WRWGTUe86/EuoKg6ZL1KEr9JoaEjNjUvXxnn/mVMZII
/n2W2liTc8whyVz9WiiuTZ904nibXASPEzj9Wq5BWXikeDMZqERJt+OW+xCjyRA/
ijnMfas/8JwxjGRcA4zf1YGFGeEt05w+zInmRlLQamibn/Ok9Ylud03utr+T/Eg=
=jTtx
-END PGP SIGNATURE-


php-7.1.21RC1.tar.gz
SHA256 hash:
c741b156b1b00182e6fb2c4462fa97a1dc48b8cf761d5a16f5d313d10d850aa7
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJbYcFvAAoJEPm6Ctoxy9ieujsH/jgCay3k7aVWCszOSIL5xMxa
8RDz5CtZiKs8NmYDqZQhDVOHnTF9Qr43xTLA57TLFULUmnATW5BcE8rdhszigtqk
Twxp9CVj/MSaioZI1WmX1jo75OsRMIlb0DuLw27bS0WdrWsYbLWE/0+uDBuolVmf
3gFlB2MITMBAKyIz0ScmHkYrgI2TH/JtMYZPHAzlDtYhDwNeDY08qK+3sy9F9uKx
J4/8e42AO5sd+OgieOs+Uan3veCny4nAy2qXXAQmPHhZEuWlps72b4K2jU1iC/3W
JOp/eQ0LIp/lp72aPultsHsOn4SEI60IilNJut9dV0X7r0bizhFBVh9SoTbwVkk=
=hrLp
-END PGP SIGNATURE-


php-7.1.21RC1.tar.xz
SHA256 hash:
9c4ed8380568c7dc1f0f6abe9f34cd8a68fa58483d55a35e1aebf24048f6c479
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJbYcFwAAoJEPm6Ctoxy9ie2zEH/1mf/O/hFbU1g/KZEUm+vnzp
oLyYAgD0ij88b8D72jYTnEnITPF231Qi7EdNGAmQS6Pksh0GEqaG5kULnhd7BbqE
gzTmlUN+oBpm82tlLzkadP1p99zIl43X4HtCUThNYOJMlWXvq88TQ9fUn3b2cSME
keEBaGlGl2oCCD0lQ1hcOA7eCVCqXJsjHzh2lJDcbx2ZbH2/t9A0E53ooWdpazeR
zfoiOkGgoNNjkPSetC2LG5a3HPkD/qZJm14LEr13OaAlvs53niFo7r4sYzayKZdM
NuNEQaXP7r5kS40Aqn/gjofIDg6j+4ni9atAwcbVY328iA4J5W5OWfS+XI5tSrs=
=3ABE
-END PGP SIGNATURE-

Cheers
Joe

[PHP-DEV] [RFC] abolish narrow margins

[Joe Watkins]

Afternoon internals,

I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
in the very near future ...

We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to
vote in the coming days ...

Cheers
Joe

Re: [PHP-DEV] [RFC] abolish narrow margins

[Joe Watkins]

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 trying to discuss and pass a
monolithic RFC that tries to solve all problems, I chose (a year ago) to
start here; Simply raising the bar simplifies the rules we currently have
and so simplifies their reform (in detail and process).

I'm not following your logic for further delaying voting on this RFC, in
fact I don't see any logic, just an assertion ;)

Cheers
Joe

On Thu, Jul 12, 2018 at 2:22 AM, Sara Golemon  wrote:

> On Wed, Jul 11, 2018 at 7:10 PM, Andrea Faulds  wrote:
> > 2/3+1 is silly, though. 2/3 already means there's twice as many agreeing
> as
> > disagreeing, having +1 doesn't serve the tie-breaking function there
> that it
> > does for 50%+1. But that was indeed a knife-edge RFC, it was actually
> saved
> > by someone chosing to vote Yes at the last minute.
> >
> I can buy that argument, but since there IS room to disagree, then
> such should be spelled out clearly in the voting update RFC.  Let's
> decide and not leave it to subjective interpretation.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] PHP 7.1.16RC1 ready for testing

[Joe Watkins]

Afternoon everyone,

PHP 7.1.16RC1 is available for testing at https://downloads.php.net/~ab

Please report any bugs you find.

Follows is verification information:

php-7.1.16RC1.tar.bz2
SHA256 hash:
f95247efac6caacf74e78a23f7ec14416cbfb66711f839af04b022559e1b1632
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJaqKzVAAoJEPm6Ctoxy9ieP8QH+gMTuHpDBBnHgpufvK3Ooy/V
RAhQ8/E++3tR6IWf9h4FZZcLSM+AJSTTnIg220iE9bYXu9F/czKMtNDiNp1QnCxH
wpNF/u7G6VzKEotB4Eq6uwYMJrgZYXBr5joKzXYt0LQ0ej+I5wvsdv+YVmfWIVCm
RPryGzDy49BZp1oft+tucIwv4as/8vaG4eX5md0auhJhDuizz8nzRb5F6OVaaOuX
Di+l958KNtPbRvgmfAYmkbvAfGMgQ9cukcVPu/QX96izPdipR9bjkSRZyKR9CLLe
FhcDA3IQHphGf6+1H5XTPUQ9qALzdMyuKpj5Tdr4cmMN0FurnVsqc41OUnKmBoA=
=+5gH
-END PGP SIGNATURE-


php-7.1.16RC1.tar.gz
SHA256 hash:
8bedfab2e264983d0fcba3e727c67ace39f0f70d63cb59148f3d911a92f2d6b9
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJaqKzWAAoJEPm6Ctoxy9ieAbAH/3b0wpSmJ9SdH6qLKdwgG58h
+d0Yy/3wZhJOnLs1jQknAVn222XBy4GTMzhriX1gHPWe5pBqU6yyWnhwxGnrbnT2
Xxj3E7182HKhUF1Xw5DPpGsYJm8YoUANrzjQOnjtV2S3bakI9wP9VaHy3k1JF2/C
q47u++3cpE3n9yIA52j19tx/kkPy40bOh8/pzIcTxcFOYyAk9R8YGdXAv3qdn/hY
VPy1j2/9uDG4KobtmSWE3KjXdUlw7ORJ9SPGtY2GW3kt8Q7L/9i1zixfh6da2jpU
ObXuzrk2g+Ol1c2X8tJvYiHREA1G/eOSM8CXO1fr3BER4ozeBO6ShScsVVX9txE=
=K7us
-END PGP SIGNATURE-


php-7.1.16RC1.tar.xz
SHA256 hash:
9ac995f48499865a7ec485ff1615f0ec451dba3a5743a9cbcc0bac8ab20ebfe3
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJaqKzWAAoJEPm6Ctoxy9iedRMIAJMsJEICyGjwEq6Ns1cQLEug
I96qJLS7OCL23696oPKwuKyIJwMsnRBK+gf+qXSrPJpfLH/q+BhNzhCLP3SG93Eb
El2shRzOEohoVqHX6PgjVznrt8evdSXjUedW4ajAQob4EkB8LdsfMDxiTTq6kvEy
JdLwqs1BCwrTFkmTtgLF/l8iC0Wzq/u660yX/n9KAAq2f+kU8hKhCqOrKeVCr6wa
OVrVn3AcCEgwp1FU4hUuyViausg2SKkPVAQSk1S/JZNSd1I2ycecHfh1jZr4pFOc
TDUa5jQgZJeoetr45q6IrxAKusovSgfQ8uo5sY++apjBAcaSg06KhKKx1gHi04s=
=aftE
-END PGP SIGNATURE-

Cheers
Joe

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

[Joe Watkins]

Evening Sara,

You forgot to mention the free cake you get for being an RM ...

Cheers
Joe

On Tue, Apr 24, 2018 at 9:03 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> > I want to encourage anyone who is "on the fence" or worried they won't
> > be able to pull it off to just go for it.  We have a large group of
> > active, experienced RMs, a decent supply of tooling, a surprising
> > amount of documentation, and if circumstances change and you just
> > can't do the job a year from now, that's no problem.  We can reshuffle
> > teams and/or provide temporary support between versions (For example,
> > I put out 7.1.13 and 7.1.14 because Davey and Joe both had
> > obligations, and that was fine).
>
> I could help as secondary RM if needed.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] PHP 7.1.15 Released

[Joe Watkins]

Afternoon,

PHP 7.1.15 has been released and is available for download at
https://downloads.php.net

Windows binaries are available on http://windows.php.net

Follows is verification information:

php-7.1.15.tar.bz2
SHA256 hash:
e117a54738e9485de5fc75673d39dbe937dd87f0f9cc9e281960ef9b961adcbd
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJamcPJAAoJEPm6Ctoxy9iecQEIAI+CKfoRYsammvdN0DEj/kGy
1sB/xPuJv+Hwx5EDKddCf65FDrm4bx4+4HAeqp/0N04NxbRAZd65tpIW5QtZuG7M
1r1lmzgYAVys4BVJNYtbUjkVqOQzglNWWrTFLKSMsBgdVLPW+fnoafj4rwLkdxDL
NbPCcLOzvxP/JYg9VLtrBaCjTJO6WjEtIQz2C7XZLQE3s7YIqqQYLa6pT+eLtSyq
9CXxv9Nw46MMhDx2t7CkdNXshZKYbE4nlnEughsygQNued6Dgkz3DgumUAIWiRHo
08EV0FKTThFk/2SBmXlE743E6d0hKt3XUXU5C6mCO1IlbgQB+vu1Y+J+PA1TnR8=
=xZCi
-END PGP SIGNATURE-


php-7.1.15.tar.gz
SHA256 hash:
0669c68a52cbd2f1cfa83354918ed03b0bcaa34ed9bafaee7dfd343461b881d4
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJamcPJAAoJEPm6Ctoxy9ieywwIAJwm3CESgN9dUu5Kgjkptmil
hh1V7P/DjcVGGADDbf+mql+CKMZWkWZhhs52x4ksiS1Em95OtnlL7pYuM8v5XBl5
s6S6uW46skUFE2AZ74NLzL3XYHNE+rZoO9J6O+Q393m6jQYoUvjtXfcuP8xYK6Rp
2QEo1tRzxo6S9zcZt/iVPXBtIckxPb3FyUjzLo6uudqgH3C2TyDwo5u9rw159bPy
+MH0kc+c3EjM8W3wRFAwbDXxL+Mtzc+4/7whLlndNDN/BZr+jyLe49fzEYJR86qx
4Hx+7dD16KQiaNzDxMhQyMH6g6O55FTeVdhp3Zv+/v7Hjnraff61B/ZoMLdRFoo=
=58/S
-END PGP SIGNATURE-


php-7.1.15.tar.xz
SHA256 hash:
0e17192fb43532e4ebaa190ecec9c7e59deea7dadb7dab67b19c2081a68bd817
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJamcPKAAoJEPm6Ctoxy9iez+kIAK1BeptPx/3FC7bFg3KhqXCf
SptgrMxTiuayBYRl74uxUTvzt9t577T59xlempQ04ZxyRq0IAQmgRI5lm81BwUqF
Cn4jIgJtFQN7c1XVzG8OXMDBFfaZNNaUf1EI0ULEwriTovnO43yLwv0kr96zeB4S
MhnnqhhJA98+oBuf6CU6zgSrSW/iuWbXwxa9toBTbq1IcbRUfRUNKBffi6RvcqTX
3Gn5XU4hu6mwphnGXGReILTOpzDzoM9Zi0ugZVtQlLjHPT+5+RU0SA8QMKhDAnSz
xvN12PdLZxRs98HOOWOMTa0Lo/A8Q337TEF3FnZdOR7MLSduJZqaEJinjY08YN0=
=33XR
-END PGP SIGNATURE-

Cheers
Joe

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Joe Watkins]

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 just used PHP_FLOAT_MIN for the first time, and was surprised that it
> is
> > the smallest **positive** number representable. Is this expected?
> >
> > This is unlike PHP_INT_MIN, which is the absolute smallest representable
> > integer, and as such is negative:
> >
> > echo PHP_INT_MIN; // -9223372036854775808
> > echo PHP_FLOAT_MIN; // 2.2250738585072E-308
> >
> > If it is intended, maybe the doc
> >  should be clear
> > about this, at the moment it is just:
> >
> > Smallest representable floating point number.
> >
> >
> > Which is confusing IMO.
> >
> > Cheers,
> > Ben
> >
>

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

[Joe Watkins]

Such complex and far reaching features should clearly have a two week
voting period, please update the RFC.

Cheers
Joe

On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov  wrote:

> Hey,
>
> I'm starting the vote on JIT RFC.
>
>
>  https://wiki.php.net/rfc/jit >
>
>
> The voting period is one week, until Thursday 28-03-2019 GMT.
>
>
> Since the initial announcement and following discussions, RFC was imprved
> and implementation extended with support for Clang, Windows and ZTS builds.
> Please reread RFC carefully.
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

No it is not, if it were, it would not need patching, it would not be doing
illegal things in ZTS mode and I wouldn't be getting shouted at by someone
not qualified to say if it works or not.

Consider me out of this conversation.

On Sat, 23 Mar 2019, 14:16 Lester Caine,  wrote:

> On 23/03/2019 12:47, Joe Watkins wrote:
> > The thing is broken
>
> The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
> that simply currently necessitates using the resource that has already
> been created rather than trying to connect again. The correct response
> to someone complaining about it is as with many other things in PHP
> simply to explain they are doing it wrong anyway.
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

You say lots of people are relying on it, but it is only you who speaks in
support of it. The thing is broken, it does bad things, there is no
maintainer, and not a huge userbase.

It's not the case that we are just kicking it out for convenience, it is
the case that we cannot keep it in phpsrc with no maintainer and no
userbase, and no good reason for it to be in phpsrc.

The thing is more or less abandoned, and at this point, since it needs work
and a maintainer, the best thing to do is move it to PECL to free it from
the release cycle of PHP so that anyone may work on it and start creating
releases at their own pace, one that suits the community you say are using
it.

Cheers
Joe

On Sat, 23 Mar 2019, 13:36 Lester Caine,  wrote:

> On 23/03/2019 12:05, Kalle Sommer Nielsen wrote:
> > 80% of this posting is more a personal blog of how you (not "we") have
> > been interacting with the PHP community (as in the PHP.net community
> > specifically). What you should have done was to reply to either me or
> > Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
> > would have been it.
>
> We as in the people who rally around when we need to to protect the
> things we think are important. There are more people today reliant on
> elements like Firebird than there were 20+ years ago and to be honest if
> you kick the interbase driver into PECL we will carry on using it
> anyway, but YES it needs some love - from someone who can navigate
> around just how resources have been changed in PHP7. The sort of
> cooperation we had while keeping several extensions available on windows
> in the past. I'm perfectly happy that I am not the only person using PHP
> with Firebird  and reliant on it continuing to be available!
>
> Now to get back to working out why Nikita's patch does not work in
> 7.2.16 ...
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

[Joe Watkins]

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, use - PHP_FLOAT_MAX.
> > > Available as of PHP 7.2.0.
> >
>
>
> I'd avoid the word "smallest". PHP_FLOAT_MIN could be described as having
> the "smallest magnitude", and -PHP_FLOAT as being "the largest magnitude,
> but negative".
>
> Perhaps:
>
> > Closest representable positive floating point number to zero. If you need
> the
> > negative number furthest from zero, use -PHP_FLOAT_MAX.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

[PHP-DEV] PHP 7.1.28 Released

[Joe Watkins]

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 list of changes is recorded in the ChangeLog.

Release Announcement: http://php.net/releases/7_1_28.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.1.28

Many thanks to all the contributors and supporters!

Cheers
Joe

Follows is verification information:

php-7.1.28.tar.bz2
SHA256 hash:
739e8733fe1fc5e69e6226da6dba7a31bacfd2e3871ad2c97a792638f22c54c9
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlyjZBMACgkQ+boK2jHL
2J4Rggf/dEss6VLdfEpKGPLI3BvOmT+Xe1juuqi+l5GfDH4XNLjjpcY8GncGoJJL
UNxtYykeQXqwYR4eBX/KCZkVcKJv7wo+VdWRxWmqjKivUsaS0ITgavfBAd/NgGf0
40/uW/878KyQ6mKXLT5Dh/u5w1cx2OB69+HUiCH7xqezLm5HFSNFwjMl2Q07TAJ+
/nnR8QO/bSAghY9EK575CmB/Xs5h5iAFyAmd32lVGY9UC8BZtZjn3e+2Z6g68O6M
mghYsngTUggg5YDIH9nRc7ATyPsRDRjQ48OQPgo+J6BGHQLooGEsSu1cCBmFWCmy
R+9hrpkW+i9xA+OYDSkygmY6QBzaMQ==
=sXDP
-END PGP SIGNATURE-


php-7.1.28.tar.gz
SHA256 hash:
4df587338d4c5dfe27050c7ac72a6b7583ecaee9d3fbfc03427667a86e081999
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlyjZBMACgkQ+boK2jHL
2J566ggAoGPhR+UBxOKRavw2BKUU9BCZhABSb5GThaWPF3SwDkbuIcm/9RtIlzcq
7oeFeVM2OQFJ3JKBB7jurza8vIdyFi1obFPe56ipm9InNe+/wJj1mz1/dHFh325Y
OF9o5QAt76z9tMXHbIWRwIZ8dYPIp2R3y+JedPPE9YxNfD41Kf7+pjJi/w3t7Rbi
JVcB0G9t/O/5JT6KNiplgXJtYUYKKhJ1hamfvSJ4vlxp6hWajj+wenwOY4LvU8XI
JQv9tCiHElVolIJMfkCv/s7q/kPgtZVFe5Ftj+EKVZmCInN5kqI7nGIE+Bypf91P
YbZwN6z4SKfz/+4A/XTHuqtPwMo+Yw==
=il8x
-END PGP SIGNATURE-


php-7.1.28.tar.xz
SHA256 hash:
45131497ec0a947e3f9145c000e8fcc1f86b46518ee3f6810d80efa2d39521e2
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlyjZBMACgkQ+boK2jHL
2J6UfggAhjt1gieZYrMyF2FU+Nph17eImi+HmDY4Qn5BCujpB0Mfa/zI1/GPuWGc
6/62pVzCv/jjyaLgL+1aVaoB2Az8VmwGZbOcqpDy08EYztD2TiqRjAVdjiu4/ag9
ZVPcAgCveRdvnyjf5Z0Dns5q8IExHBYwX6BZieq3EfUXZCXjbEdVR0X+zPLl7yi9
A6pnmiTK56Qv4qjtz0aO8Fy4HY+eENXAuHRy6PuWfco+uC/0ClFA7jtWATADTTpq
J52PI/mJWyr3M2Uog5xyhDwM0S4I4KXwvbr4E0F5vABtFVzhqRBOmziSKW8itKgk
6kfJ4ORIHEuZkl/4WFfCOIgYHJ7Qlw==
=xERw
-END PGP SIGNATURE-

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

[Joe Watkins]

Afternoon internals,

Abolish Short Votes is now in voting:
https://wiki.php.net/rfc/abolish-short-votes

Cheers
Joe

[PHP-DEV] Re: PHP 8 Preview Releases

[Joe Watkins]

Hi Dmitry,

I'm not suggesting we do it right now, I'm suggesting we look at the
planning of it right now as it deviates from our normal release cycle.

At the moment we should just consider how we want it to work, including
when it should start ...

Cheers
Joe

On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov  wrote:

> Hi Joe,
>
>
> I think, PHP-8 preview is too early.
>
> We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> features (may be I forgot something) only deprecations and some internal
> improvements
>
> .
>
> According to JIT, it's probably going to be changed a lot in the nearest
> future.
>
>
> Thanks. Dmitry.
> --
> *From:* Joe Watkins 
> *Sent:* Friday, March 29, 2019 3:40:04 PM
> *To:* release-manag...@php.net; PHP internals; Dmitry Stogov
> *Subject:* PHP 8 Preview Releases
>
> Morning internals,
>
> Since we now have a result for JIT and we know it will be included in PHP
> 8, I think it's time to visit the idea brought up in discussion to have
> preview releases of PHP 8.
>
> I'm interested in hearing what kind of schedules we think are going to be
> useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
> bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
> or too fast.
>
> Thoughts please (especially from Dmitry) ?
>
> Cheers
> Joe
>
>
>

[PHP-DEV] PHP 8 Preview Releases

[Joe Watkins]

Morning internals,

Since we now have a result for JIT and we know it will be included in PHP
8, I think it's time to visit the idea brought up in discussion to have
preview releases of PHP 8.

I'm interested in hearing what kind of schedules we think are going to be
useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
or too fast.

Thoughts please (especially from Dmitry) ?

Cheers
Joe

Re: [PHP-DEV] Status of pickle?

[Joe Watkins]

Morning Levi,

For me, as author of many extensions, pickle becomes valuable at the point
when composer supports it and we have another route to deployment built
into composer.

Currently, there is no remarkable difference between using pecl or pickle
to build, except pecl is available everywhere, and pickle is only available
after an additional dep in composer.json.

I'm not sure of the exact reasons why the project lost traction, there
seemed to be some disagreement about how to move forward between developers
of pickle and composer.

Cheers
Joe

On Thu, 28 Mar 2019 at 16:40, Levi Morrison  wrote:

> I was reviewing the options for installing extensions on a per-project
> basis. The most recent effort I have found was pickle. Can someone
> more knowledgeable chime in on the status of the project? I'm also
> interested in why it hasn't gained more traction.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [VOTE] [Result] JIT

[Joe Watkins]

Morning Dmitry,

Thanks for all your hard work on this, thanks also to Anatol for making
Windows and ZTS happen.

Thank you in advance for all the work to come :)

PHP 8 is going to be quite special, I think, I look forward to it ..

Cheers
Joe

On Fri, 29 Mar 2019 at 09:58, Dmitry Stogov  wrote:

> Hi @internals,
>
>
> The JIT RFC https://wiki.php.net/rfc/jit is accepted to be merged into
> PHP-8 only.
>
> I'm going to perform the actual merge on Monday morning and then start
> working on deeper integration of JIT with VM.
>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

Specifically the events interface is broken all versions of PHP 7:

  - In a non-zts build, it executes user code allocated in Thread A in
Thread B - that's not allowed.
  - In a zts build, it makes the same mistake as above, and uses a TSRM API
to set context which itself has been broken since PHP 7.0.

It so happens that PHP 8 has broken the build, but specifically that part
of the extension has been broken since PHP 7.0.

Cheers
Joe



On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker  wrote:

> On 29.03.2019 at 10:29, Benjamin Eberlei wrote:
>
> > On Fri, Mar 29, 2019 at 10:20 AM Lester Caine 
> wrote:
> >
> >> Currently building 'interbase' extension has been turned off because
> >> it's failing to pass the changes in master for thread safe operation. I
> >> understand that it needs someone to work on it and I would love to be
> >> able to do that but it's development requirements have moved outside the
> >> area that I can cope with. And many people reliant on it are in the same
> >> boat, just as they would not be able to contribute to writing code for
> >> Firebird itself. While not perfect, what we have currently does it's job
> >> just as PHP5.2 still works on legacy hosting. PDO hopefully will remain
> >> available, but re-writing 20 years worth of code base for that different
> >> way of working has the same problem as finding resources to update the
> >> interbase extension.
> >
> > PHP needs to support thread safety in all its extensions, but that
> doesn't
> > mean its required for PECL extensions. You probably run PHP in NTS mode,
> > and if the interbase extension supports that, no need to add thread
> safety
> > support while in PECL. The problem is that every extension in php-src
> MUST
> > support it, because php supports it.
> >
> > To me it feels you are blowing this issue way out of proportion. Please
> > believe everyone trying to tell you over and over again that you have
> > nothing to fear from this unbundling.
>
> ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
> 7.4 though), since PR #3976[1] has been merged.  It will certainly be
> fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
> will be accepted it might never get fixed.
>
> [1] 
> [2] 
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

No, it's broken in both modes.

In NTS mode, both the thread that handles events (which illegally calls
user code) and the main thread are executing concurrently, they may both be
calling functions that cause interaction with module globals, which are
obviously shared between threads in NTS mode.

You cannot just start threads and execute user code from anywhere, it's not
safe in NTS mode and is a horrible violation of share nothing in ZTS mode.
It's much more likely to break ZTS mode than NTS, but illegal in both.

Cheers
Joe

On Fri, 29 Mar 2019 at 12:22, Benjamin Eberlei  wrote:

>
>
> On Fri, Mar 29, 2019 at 10:59 AM Joe Watkins  wrote:
>
>> Specifically the events interface is broken all versions of PHP 7:
>>
>>   - In a non-zts build, it executes user code allocated in Thread A in
>> Thread B - that's not allowed.
>>   - In a zts build, it makes the same mistake as above, and uses a TSRM
>> API to set context which itself has been broken since PHP 7.0.
>>
>> It so happens that PHP 8 has broken the build, but specifically that part
>> of the extension has been broken since PHP 7.0.
>>
>
> But I am correct to understand the code still compiles and works in NTS
> mode, so its not completely broken, only on ZTS.
>
>>
>> Cheers
>> Joe
>>
>>
>>
>> On Fri, 29 Mar 2019 at 10:40, Christoph M. Becker 
>> wrote:
>>
>>> On 29.03.2019 at 10:29, Benjamin Eberlei wrote:
>>>
>>> > On Fri, Mar 29, 2019 at 10:20 AM Lester Caine 
>>> wrote:
>>> >
>>> >> Currently building 'interbase' extension has been turned off because
>>> >> it's failing to pass the changes in master for thread safe operation.
>>> I
>>> >> understand that it needs someone to work on it and I would love to be
>>> >> able to do that but it's development requirements have moved outside
>>> the
>>> >> area that I can cope with. And many people reliant on it are in the
>>> same
>>> >> boat, just as they would not be able to contribute to writing code for
>>> >> Firebird itself. While not perfect, what we have currently does it's
>>> job
>>> >> just as PHP5.2 still works on legacy hosting. PDO hopefully will
>>> remain
>>> >> available, but re-writing 20 years worth of code base for that
>>> different
>>> >> way of working has the same problem as finding resources to update the
>>> >> interbase extension.
>>> >
>>> > PHP needs to support thread safety in all its extensions, but that
>>> doesn't
>>> > mean its required for PECL extensions. You probably run PHP in NTS
>>> mode,
>>> > and if the interbase extension supports that, no need to add thread
>>> safety
>>> > support while in PECL. The problem is that every extension in php-src
>>> MUST
>>> > support it, because php supports it.
>>> >
>>> > To me it feels you are blowing this issue way out of proportion. Please
>>> > believe everyone trying to tell you over and over again that you have
>>> > nothing to fear from this unbundling.
>>>
>>> ext/interbase is indeed broken (i.e. uncompilable) in master (not PHP
>>> 7.4 though), since PR #3976[1] has been merged.  It will certainly be
>>> fixed, if the “Unbundle ext/interbase” RFC[2] will be declined; if it
>>> will be accepted it might never get fixed.
>>>
>>> [1] <https://github.com/php/php-src/pull/3976>
>>> [2] <https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase>
>>>
>>> --
>>> Christoph M. Becker
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>

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

[Joe Watkins]

> A compromise between the two positions could be to allow voting to be
extended ONCE, and only within the first X% of the voting period. So, if
someone calls for a 14 day voting period, within the first 7 days they can
extend it at most one time, and it can never be extended after the first 7
days.

It's tempting to try and encode "requirements" into rules, but we're not
looking to make complicated rules and the only requirement we have is that
votes should last at least two weeks for everything. The simpler the rules
are, the better for everyone.

> Also, if you are going to be updating the language anyway, why not
specify that an exact date and time be given for when voting will end. I
think most people already do this - but this would codify it and prevent
the possibility of ambiguity in the future.

We have to deal with real life, and the fact is that hardly anyone can
schedule their lives around their contributions to PHP: Days seem to be an
exact enough measure, and as you say, some people do give a time when the
vote will close anyway. However, declaring they must isn't very realistic -
if they miss closing the vote by 15 minutes, does it invalidate the vote ?
Are we going to invent a set of criteria that would invalidate the vote ?
This seems like a rabbit hole we need not get stuck in.

Cheers
Joe

On Fri, 22 Mar 2019 at 17:01, Chase Peeler  wrote:

>
> On Fri, Mar 22, 2019 at 3:41 AM Joe Watkins  wrote:
>
>> Morning Niklas,
>>
>> Allowing the extension of voting leaves us open to someone extending the
>> voting period simply because they don't feel like they have the result
>> they
>> wanted.
>>
>> The problem we're trying to solve is votes that are too short, while
>> providing the flexibility to have longer votes, but we need to know at the
>> start of voting what the voting period is going to be. Take for example
>> the
>> case where a third party to an RFC is planning some work based on the
>> results of the voting, it doesn't seem fair that their schedule could be
>> interfered with by the first party after voting starts.
>>
>> In the vast majority of cases where someone forgets or isn't aware of a
>> holiday period, they are going to be told on day one of voting (if not
>> before, during discussion), and can simply adjust the voting period, and
>> restart the vote (if there has been any votes at the first interjection)
>> without having lost any time.
>>
>> First, I don't even have a vote. Second, I'd be ambivalent about the
> ability to extend voting even if I did. A compromise between the two
> positions could be to allow voting to be extended ONCE, and only within the
> first X% of the voting period. So, if someone calls for a 14 day voting
> period, within the first 7 days they can extend it at most one time, and it
> can never be extended after the first 7 days.
>
> Also, if you are going to be updating the language anyway, why not specify
> that an exact date and time be given for when voting will end. I think most
> people already do this - but this would codify it and prevent the
> possibility of ambiguity in the future.
>
>
>> Cheers
>> Joe
>>
>> On Fri, 22 Mar 2019 at 08:19, Niklas Keller  wrote:
>>
>> > Resend, because sent from the wrong address previously.
>> >
>> > +1, but it should probably be possible to extend the voting period once
>> > started, but not shorten it. This allows for extension during holidays
>> in
>> > case the author didn't think about that when starting the vote.
>> >
>> > Regards, Niklas
>> >
>> > Joe Watkins  schrieb am Do., 21. März 2019, 19:20:
>> >
>> > > Evening internals,
>> > >
>> > > I'd like to raise for discussion another minor, self contained change
>> to
>> > > the voting RFC:
>> > >
>> > > https://wiki.php.net/rfc/abolish-short-votes
>> > >
>> > > This seems like another no-brainer to improve and clarify the voting
>> > > process. As with abolishing narrow margins, I'm focused on this one
>> > detail
>> > > and wider discussion of how we may improve other parts of the voting
>> RFC
>> > is
>> > > not appropriate in this thread: We either have a consensus that this
>> > detail
>> > > should be changed or we don't, we do not need to discuss any other
>> > details
>> > > here.
>> > >
>> > > Cheers
>> > > Joe
>> > >
>> >
>>
> --
> -- Chase
> chasepee...@gmail.com
>

Re: [PHP-DEV] print with newline

[Joe Watkins]

Sara, where do I send pull requests?

 wrote:

> I've always wondered why PHP didn't have a built in command or function
> that behaved as `echo` but with a EOL.
> I propose not to modify `print` or `echo` (as this was rightly pointed out
> to cause b/c). How difficult would it be to add a new statement and/or
> function to the PHP core called `say` / `say()` that has an EOL?
>
> This seems to me to be simple to do. The benefit is less code to type in
> user land (ex: `say 'Hello World';` as opposed to `echo 'Hello World' .
> PHP_EOL;`
>

Re: [PHP-DEV] print with newline

[Joe Watkins]

Afternoon Steven,

I'm not going to apologize for making a joke ... it was a joke ...

That being said, if you insist on pursuing an RFC for this, and would like
to get on with writing that RFC, then here is an initial patch:
https://gist.github.com/krakjoe/efff492611ce8f9fc12909023c89c7dc

Let compile time optimization of the call be implemented if the feature is
accepted, and don't worry about doing that yourself.

I haven't changed my mind, this is not justified in my opinion, but it is
just my opinion and I could have been more helpful yesterday ...

Cheers
Joe

On Mon, 4 Mar 2019 at 16:30, Steven Penny  wrote:

> On Mon, 04 Mar 2019 02:23:46, Peter Kokot wrote:
> > Now, interesting is that in bash and some langs (where the main
> > environment is CLI), there is by default newline echoed. In PHP and
> > other languages there isn't. Changing default functionality of echo in
> > PHP is like changing left-hand traffic countries to use right-hand
> > traffic. A new function name would be needed for that. You can start
> > with creating an extension for this.
>
> I think the best option is a new function like "puts" or "posix_puts". I
> looked
> into this but im having trouble. i started with "var_dump" because that
> does
> produce a newline by default [1]:
>
> php_printf("%sbool(false)\n", COMMON);
>
> new function would be most similar to "print", so i went to look at that
> code,
> but it seems "print" uses "echo" internally [2]:
>
> opline = zend_emit_op(NULL, ZEND_ECHO, _node, NULL);
>
> so then i went to look at "echo" code. however i cant actually seen to find
> where that is defined, as the PHP codebase is... byzantine. it seems
> ZEND_ECHO
> is handled by "zend_write" [3]:
>
> zend_write(ZSTR_VAL(str), ZSTR_LEN(str));
>
> which is handled by "write_function" [4]:
>
> zend_write = (zend_write_func_t) utility_functions->write_function;
>
> which is handled by "php_output_write" [5]:
>
> zuf.write_function = php_output_write;
>
> which is handled by "php_output_op" [6]:
>
> php_output_op(PHP_OUTPUT_HANDLER_WRITE, str, len);
>
> which is handled by "ub_write" [7]:
>
> sapi_module.ub_write(context.out.data, context.out.used);
>
> which is handled by "orig_ub_write" [8]:
>
> sapi_module.ub_write = orig_ub_write;
>
> which is handled by... "ub_write"? [9]:
>
> size_t (*orig_ub_write)(const char *str, size_t str_length) =
> sapi_module.ub_write;
>
> it seems like a circular definition. surely i am getting something wrong,
> and
> is it really need to go 8 levels of abstraction to write to standard
> output?
>
> [1] https://github.com/php/php-src/blob/df57395/ext/standard/var.c#L109
> [2] https://github.com/php/php-src/blob/df57395/Zend/zend_compile.c#L7361
> [3] https://github.com/php/php-src/blob/df57395/Zend/zend_vm_def.h#L1584
> [4] https://github.com/php/php-src/blob/df57395/Zend/zend.c#L810
> [5] https://github.com/php/php-src/blob/df57395/main/main.c#L2140
> [6] https://github.com/php/php-src/blob/df57395/main/output.c#L255
> [7] https://github.com/php/php-src/blob/df57395/main/output.c#L1076
> [8]
> https://github.com/php/php-src/blob/df57395/ext/opcache/ZendAccelerator.c#L4211
> [9]
> https://github.com/php/php-src/blob/df57395/ext/opcache/ZendAccelerator.c#L4126
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

Hi all,

It would be nice to hear from Peter , do you want to take on this role ?

You would have my vote, obviously, but we like people to volunteer, it's
not a small or short commitment.

Cheers
Joe

On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen  wrote:

> Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov :
> >
> > On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann 
> wrote:
> >
> > > Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:
> > > > I'd like to suggest Peter Kokot for this role.
> > >
> > > Seconded.
> > >
> >
> > Thirded.
>
> Fourthed.
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

Thanks for all the effort Dmitry, it's looking in much better shape.

Cheers
Joe

On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov  wrote:

> Hi Internals,
>
>
> The RFC and implementation was updated once again.
>
>
> https://wiki.php.net/rfc/jit
>
>
> Now JIT supports PHP builds with compilers without GCC explicit global
> register variables extension.
>
> This means we support CLANG/LLVM (Tested on Linux. Should work on Mac as
> well) and MSVC.
>
> Complete Windows support is not implemented yet, but I don't see any big
> problems anymore.
>
>
> ZTS support might be implemented after implementation of proposed TSRM API
> improvement.
>
>
> Thanks. Dmitry.
>
>
> 
> From: Dmitry Stogov 
> Sent: Wednesday, February 13, 2019 16:07
> To: PHP internals
> Subject: Re: [PHP-DEV] [RFC] JIT
>
> Hi Internals,
>
> According to comments, code reviews and discussions, JIT RFC was
> extended with few new sections.
>
> Please, consider to review the RFC once again.
>
> https://wiki.php.net/rfc/jit
>
> Any suggestion for RFC improvement are welcome.
>
> I'm not going to invest significant time into JIT implementation
> improvement itself, at this point. So, ideas are also welcome, but don't
> expect to get them implemented tomorrow.
>
> Thanks. Dmitry.
>
> On 1/31/19 12:43 PM, Dmitry Stogov wrote:
> > Hi Internals,
> >
> >
> > I'm glad to finally propose including JIT into PHP.
> >
> >
> > https://wiki.php.net/rfc/jit
> >
> >
> > In the current state it may be included both into PHP-8, where we are
> > going to continue active improvement, and into PHP-7.4, as an
> > experimental feature.
> >
> >
> > Thanks. Dmitry.
> >
>

[PHP-DEV] [RFC] [Accepted] Abolish Narrow Margins

[Joe Watkins]

Morning all,

The abolish narrow margins RFC has been accepted and the Voting RFC has
been updated and had it's version changed to 1.1

Cheers
Joe

[PHP-DEV] [RFC][Vote] Weakrefs

[Joe Watkins]

Morning all,

The vote for weakrefs is open: https://wiki.php.net/rfc/weakrefs

Cheers
Joe

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

[Joe Watkins]

Whoever creates the pecl package would be listed as maintainer, which may
explain silence :)

I'm not sure who has karma for creating repos on git.php.net either, I may ?

Cheers
Joe

On Mon, 25 Feb 2019, 12:10 Christoph M. Becker,  wrote:

> On 11.02.2019 at 19:42, Christoph M. Becker wrote:
>
> > On 31.01.2019 at 23:19, Christoph M. Becker wrote:
> >
> >> The voting on
> >>
> >>   
> >>
> >> has ended, and it has unanimously been decided (30:0) to remove (aka.
> >> unbundle) ext/wddx; it has also been decided (19:4:3:2) to deprecate the
> >> extension and move it to PECL.  Thanks to all voters!
> >
> > Could someone with sufficient karma please move ext/wddx (PHP-7.4+) to
> > PECL/wddx?  (Also the respective info in README.RELEASE_PROCESS[2] could
> > need some update.)
>
> Anyone?  I guess I have sufficient karma to do the actual move, but
> someone would have to set up PECL/wddx in the first place.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] print with newline

[Joe Watkins]

As a function it has parity with fputs ... even though fputs doesn't have
the same behaviour the two can be considered complimentary, and you would
want to be able to cuf(a) puts like fputs.

Regardless an RFC may go ahead without optimized implementation.

Cheers
Joe

On Sun, 10 Mar 2019, 20:28 Thomas Punt,  wrote:

> > From: Steven Penny 
> > Sent: 04 March 2019 15:30
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] print with newline
> >
> > I think the best option is a new function like "puts" or "posix_puts".
>
> I'm fairly neutral on the feature, but I disagree with this being a
> function.
> It should be a language construct for parity with the echo and print.
>
> For what it's worth, I actually wrote an article about exactly this. Whilst
> it was more for didactic reasons (meaning that parts of the implementation
> could/should be changed), you may find it to be a nice read:
>
> https://phpinternals.net/articles/implementing_new_language_constructs_via_opcode_extending
>
> Cheers,
> Tom
>

[PHP-DEV] PHP 7.1.27 Released

[Joe Watkins]

Afternoon,

The PHP development team announces the immediate availability of PHP
7.1.27. This is a security release.

All PHP 7.1 users are encouraged to upgrade to this version.

For source downloads of PHP 7.1.27 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: http://php.net/releases/7_1_27.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.1.27


Many thanks to all the contributors and supporters!

Cheers
Joe

[PHP-DEV] PHP 7.1.27 Release Verification

[Joe Watkins]

Apologies,

I missed the verification info for 7.1.27:

php-7.1.27.tar.bz2
SHA256 hash:
dad7ecd30941911528e471c555a01911a68aa9219696bfc1e005f8b669f4ec4b
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJcfs5MAAoJEPm6Ctoxy9iedkYH/2IyMTgmUGfPQdK96nXGZX8T
Zw3yDm9ll+vVuKYdhBVuQs5YlK5pR0zuve6LJ/xdmnIipZYo06mQYS4nlfpjU6gk
lpwX1KkitqUE0RbJqnd29HO8pcP/oTiiK97uuiLhcFtcfG2vhJlmaLs3synn+KDR
vXmrEx5QmYbNNZNIxcMnhhLW628P9QUgpO2SG+ktM4BHPwa4S6lfXL/r2327VBH/
8p/o+ChXeTM5RRV3IGQ83Vrzp9/dAXvuQNZQZMSKdJmDeamDHs+LbhICIFPQscap
kvs0oRGK52H5Ds8Q063+TQwwbaloL/yLvowJckevJy23ISNS9YHwF/yYMzz98K4=
=ETQy
-END PGP SIGNATURE-


php-7.1.27.tar.gz
SHA256 hash:
353b9ed341048388cc95e6fa6dab587eee44a3d4d297989aa297936090864357
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJcfs5MAAoJEPm6Ctoxy9ieCwoH/0xoyiHHwgdhDhmoqmpKO25y
c2aNBkji4wdhDlIg/6CUZK9IGyZ+LXTLHS99ZUSgbvVGBUh3p9B0BG6kRjR6+dU9
Cyh4VFB7+pGYFfQj1o8Cqpl6FsQh6EbGVo5miije/y99TlxpgFE4LFYAY5Woq8WI
Q4YZYXtRnSlWex+/JmWGCfuRYKF9jmMIF18psDYSZqx1e8U/ztX8pPM/Ry1QgrHl
+NyaJUBaohyYDe0ARSzM50/ks8Oo/LEE2ruofF440fDpU5yT/ii7Bxq4/bgNziN7
uaVchlpIiOPCHKryuRwYYZE/xbhaod7kADHEmecxV4mLCZqYRHQIura+2BjdImQ=
=x2x+
-END PGP SIGNATURE-


php-7.1.27.tar.xz
SHA256 hash:
25672a3a6060eff37c865a0c84e284da50b7ee8cd57174c78f0ae244b90a96a8
PGP signature:
-BEGIN PGP SIGNATURE-

iQEcBAABCAAGBQJcfs5NAAoJEPm6Ctoxy9ieyKMH/2uUR0oqmBgzS8TEzYJ4JQ0f
7/vlLKT8ytLh5kyChiMFotKZBbXGk+VQyy3gqbUrysVsGTxh5gbQg+k8Fsg4x+AA
dW5xsAVGPGNlS1gQ0OPOf5cNEEFz85t3Fzu9Msq2N23uh/of6scTzTYGFgUnUf73
qBspk85Pf2OtCEzjNCJDWlr3cM8gfybgn9SvsYbSwyROsqdiM34aIwrLHZg7D5N/
qXj/DQJrTUKwz4tLEeO5WgYJ75fcYkaoRlYIc4wwkAK55XEmnmMzVHUUj8pAeaXp
F/y019vZ4bdA38ESHUrRvRB4qs9VDHworajjcIYSCRU584wLdj1VhRptQTyB3K4=
=uavC
-END PGP SIGNATURE-

Cheers
Joe

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

[Joe Watkins]

They sound like justifications for 5.6 support being extended.

I think there are good reasons to stick to schedule for 7.4: 8.0 is certain
to contain JIT, 7.4 is not, but should 7.4 get the JIT then it will be
experimental, and because of ABI guarantees and BC concerns will be more or
less stale in the 7.4 branch, with a focus on 8. It will not be good to
have an experimental feature being used in production for an additional
year. If 7.4 doesn't get the JIT then that's a really good reason to
upgrade to 8, which will help adoption, and extending support will harm
adoption.

The upgrade from 7.4 to 8 for tools like smarty should be relatively
painless, if any changes are needed at all they will be quick and easy. The
same for third party extensions most likely ... This isn't comparable to
5.6 to 7 where rather a lot of extension code needed to be rewritten, and
userland code may have been broken.

What is clear is that we should not be adjusting policy with extended
support for the last release in a series, if we are going to extend support
then it should be for reasons beyond "it's the final release in this
series".

Cheers
Joe

On Tue, 19 Mar 2019, 20:50 Björn Larsson,  wrote:

> Den 2019-03-19 kl. 17:53, skrev Sebastian Bergmann:
> > Am 19.03.2019 um 17:43 schrieb Joe Watkins:
> >> At least I'd like someone to explain in detail why we should extend
> >> support
> >> for 7.4?
> >
> > Seconded.
> >
> For us the extended support of 5.6 has been very beneficial.
> Primarily for two reasons:
> - A large legacy code base that took time to fix.
> - Adaption of third-party tools takes time. For instance latest
>version of smarty that we use, still gives error messages for
>PHP 7.3 (a standard plugin).
>
> I don't expect the above to change going from 7.4 to 8.0. Of
> course it depends on the 8.0 features and BC breaks.
>
> Also looking at the 7.4 content it seems quite attractive! So
> given that we don't yet know uptake of 8.0, 7.4 could have
> a long lifespan.
>
> Another point is that when looking in the control panel for
> our server that incorporates PHP, 5.6.40 is listed as outdated.
> If it had been a year ago instead (no extended support ), then
> it would have felt weird since 5.6 has executed flawlessly in
> 2018 for us.
>
> Finally, given that the extended support for 5.6 has been quite
> a success, having the same for 7.4 seems prudent at this point
> in time.
>
> r//Björn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

https://pecl.php.net/package/wddx

Cheers
Joe

On Wed, 20 Mar 2019 at 13:03, Christoph M. Becker  wrote:

> On 13.03.2019 at 20:47, Christoph M. Becker wrote:
>
> > Still, I'm looking for someone who is willing to create a new home for
> > ext/wwdx on PECL.
>
> This is just a gentle reminder that somebody should please create a new
> home for ext/wddx on PECL.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

Looks like someone done that too, I think you have everything you need now ?

Cheers
Joe

On Wed, 20 Mar 2019 at 13:29, Christoph M. Becker  wrote:

> On 20.03.2019 at 13:09, Joe Watkins wrote:
>
> > https://pecl.php.net/package/wddx
>
> Thanks Joe!  My request was badly worded, though.  Actually, I need
> somebody to create a respective Git repo (something like
> pecl/xml/wddx.git).
>
> > On Wed, 20 Mar 2019 at 13:03, Christoph M. Becker 
> wrote:
> >
> >> On 13.03.2019 at 20:47, Christoph M. Becker wrote:
> >>
> >>> Still, I'm looking for someone who is willing to create a new home for
> >>> ext/wwdx on PECL.
> >>
> >> This is just a gentle reminder that somebody should please create a new
> >> home for ext/wddx on PECL.
>
> --
> Christoph M. Becker
>

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

[Joe Watkins]

Maybe put a readme in the git repo ...

Cheers
Joe

On Wed, 20 Mar 2019 at 14:04, Nikita Popov  wrote:

> On Wed, Mar 20, 2019 at 1:43 PM Joe Watkins  wrote:
>
>> Looks like someone done that too, I think you have everything you need
>> now ?
>>
>> Cheers
>> Joe
>>
>> On Wed, 20 Mar 2019 at 13:29, Christoph M. Becker 
>> wrote:
>>
>> > On 20.03.2019 at 13:09, Joe Watkins wrote:
>> >
>> > > https://pecl.php.net/package/wddx
>> >
>> > Thanks Joe!  My request was badly worded, though.  Actually, I need
>> > somebody to create a respective Git repo (something like
>> > pecl/xml/wddx.git).
>> >
>> > > On Wed, 20 Mar 2019 at 13:03, Christoph M. Becker 
>> > wrote:
>> > >
>> > >> On 13.03.2019 at 20:47, Christoph M. Becker wrote:
>> > >>
>> > >>> Still, I'm looking for someone who is willing to create a new home
>> for
>> > >>> ext/wwdx on PECL.
>> > >>
>> > >> This is just a gentle reminder that somebody should please create a
>> new
>> > >> home for ext/wddx on PECL.
>> >
>> > --
>> > Christoph M. Becker
>> >
>>
>
> I've set up the git.php.net repo and github mirror, imported the ext/wddx
> directory as of PHP-7.4 (doing this for the first time, hope it's right)
> and gave you karma for the repo.
>
> Nikita
>

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

[Joe Watkins]

I'm not so sure it's worth adopting as policy. It's.my understanding that
5.6 was extended for reasons that may not apply to the 7.4-8 upgrade. It's
likely less painful, it's likely better prepared with 7.4 raising
appropriate deprecation notices and such.

At least I'd like someone to explain in detail why we should extend support
for 7.4?

Cheers
Joe

On Tue, 19 Mar 2019, 15:54 Sara Golemon,  wrote:

> On Tue, Mar 19, 2019 at 9:49 AM Remi Collet 
> wrote:
> > >> Yay! And on that topic, did we come to a consensus on whether or not
> 7.4
> > > was going to have an extended support cycle the way 5.6 did? If so, how
> > > long was it?
> >
> > 5.6 support, as latest 5.x, was extended by 1 year
> >
> > I think it make sense to do the same for latest 7.x
> > (so 2 years of security instead of 1)
> >
> I agree and think it's worth putting such into the release process as
> standard practice.
>
> -Sara
>

Re: [PHP-DEV] Mitigate “Magellan vulnerabilitites” in PHP 7.2?

[Joe Watkins]

Cheery picked into 7.1

Cheers
Joe

On Mon, 11 Mar 2019 at 17:35, Christoph M. Becker  wrote:

> On 19.02.2019 at 02:16, Stanislav Malyshev wrote:
>
> >> In my opinion, adding this ini setting to PHP-7.4 is a no brainer, but I
> >> suggest that we backport it to PHP-7.2 as well.
> >
> > I don't see a reason why not - if the option is useful for improving
> > security/stability, let's backport it. If it's security related, maybe
> > even to 7.1 since it's still in security support (if it's not too hard).
>
> I have applied the PR[1] to PHP-7.2+.  Joe may consider to cherry-pick
> to 7.1.
>
> [1] 
>
> --
> Christoph M. Becker
>

[PHP-DEV] [RFC][Accepted] weakrefs

[Joe Watkins]

Morning internals,

The vote for weakrefs is closed and has been accepted.

Because of feedback received very late during voting from non-voting
contributors/community members, the implementation will be slightly
different to that in the RFC - it was pointed out that it's more useful if
there is only one weakref for every object, and it happens to simplify the
internal implementation also. The only difference is the __construct will
be replaced with a named constructor so that we may achieve this: It will
still have the same interface as accepted, but with a different name for
constructor and simpler implementation.

Cheers
Joe

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

[Joe Watkins]

Afternoon Dmitry,

> If you liked to change this, you might do it together with 50%+1 -> 2/3
majority change.

The super majority RFC was already accepted ...

> If you agree, I can extend voting period "pseudo proportionally" (to be
1.5 week), but I don't like to lose the following week.

I'm not sure what you loose, I'm sure that you gain the possibility of more
voters having the opportunity to vote.

Cheers
Joe

On Thu, 21 Mar 2019 at 14:11, Dmitry Stogov  wrote:

> Hey Joe,
>
>
> Voting rules nothing say about "complex features" and 2 weeks voting
> period.
>
> If you liked to change this, you might do it together with 50%+1 -> 2/3
> majority change.
>
>
> If you agree, I can extend voting period "pseudo proportionally" (to be
> 1.5 week), but I don't like to lose the following week.
>
>
> Thanks. Dmitry.
>
>
> --
> *From:* Joe Watkins 
> *Sent:* Thursday, March 21, 2019 3:12:31 PM
> *To:* Dmitry Stogov
> *Cc:* PHP internals
> *Subject:* Re: [PHP-DEV] [RFC] [VOTE] JIT
>
> Such complex and far reaching features should clearly have a two week
> voting period, please update the RFC.
>
> Cheers
> Joe
>
> On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov  wrote:
>
> Hey,
>
> I'm starting the vote on JIT RFC.
>
>
>  https://wiki.php.net/rfc/jit<https://wiki.php.net/rfc/typed_properties_v2
> >
>
>
> The voting period is one week, until Thursday 28-03-2019 GMT.
>
>
> Since the initial announcement and following discussions, RFC was imprved
> and implementation extended with support for Clang, Windows and ZTS builds.
> Please reread RFC carefully.
>
>
> Thanks. Dmitry.
>
>

[PHP-DEV] [RFC] Abolish Short Votes

[Joe Watkins]

Evening internals,

I'd like to raise for discussion another minor, self contained change to
the voting RFC:

https://wiki.php.net/rfc/abolish-short-votes

This seems like another no-brainer to improve and clarify the voting
process. As with abolishing narrow margins, I'm focused on this one detail
and wider discussion of how we may improve other parts of the voting RFC is
not appropriate in this thread: We either have a consensus that this detail
should be changed or we don't, we do not need to discuss any other details
here.

Cheers
Joe

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

[Joe Watkins]

Morning Kalle,

Seems like a reasonable plan, +1

Cheers
Joe

On Fri, 22 Mar 2019 at 14:26, Kalle Sommer Nielsen  wrote:

> G'day internals
>
> I'd like to start the discussion for the future of the ext/interbase
> extension:
> https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase
>
> The rationale for pushing this extension out of the core is mentioned
> in the RFC.
>
> Unless there is any serious issues raised here, then I will put this
> into voting on Monday 8th of April, noon EET (which is a good two and
> a half weeks away). The intended voting period is set for 2 weeks,
> meaning if voting proceeds, the pools will be closed around Monday
> 22th of April, noon EET.
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

Morning Niklas,

Allowing the extension of voting leaves us open to someone extending the
voting period simply because they don't feel like they have the result they
wanted.

The problem we're trying to solve is votes that are too short, while
providing the flexibility to have longer votes, but we need to know at the
start of voting what the voting period is going to be. Take for example the
case where a third party to an RFC is planning some work based on the
results of the voting, it doesn't seem fair that their schedule could be
interfered with by the first party after voting starts.

In the vast majority of cases where someone forgets or isn't aware of a
holiday period, they are going to be told on day one of voting (if not
before, during discussion), and can simply adjust the voting period, and
restart the vote (if there has been any votes at the first interjection)
without having lost any time.

Cheers
Joe

On Fri, 22 Mar 2019 at 08:19, Niklas Keller  wrote:

> Resend, because sent from the wrong address previously.
>
> +1, but it should probably be possible to extend the voting period once
> started, but not shorten it. This allows for extension during holidays in
> case the author didn't think about that when starting the vote.
>
> Regards, Niklas
>
> Joe Watkins  schrieb am Do., 21. März 2019, 19:20:
>
> > Evening internals,
> >
> > I'd like to raise for discussion another minor, self contained change to
> > the voting RFC:
> >
> > https://wiki.php.net/rfc/abolish-short-votes
> >
> > This seems like another no-brainer to improve and clarify the voting
> > process. As with abolishing narrow margins, I'm focused on this one
> detail
> > and wider discussion of how we may improve other parts of the voting RFC
> is
> > not appropriate in this thread: We either have a consensus that this
> detail
> > should be changed or we don't, we do not need to discuss any other
> details
> > here.
> >
> > Cheers
> > Joe
> >
>

Re: [PHP-DEV] Wiki RFC karma request

[Joe Watkins]

Hi Adrian,

Thanks for your interest in contributing to PHP, the necessary karma has
been granted to you.

I will just mention that I believe there's more than one person working on
annotation proposals as well as declined proposals, it would be a good idea
to liaise with current and past authors on this subject.

Cheers
Joe

On Wed, 6 Feb 2019 at 12:52, Adrian Modliszewski <
adrian.modliszew...@gmail.com> wrote:

> I'd like to do some work on an Annotation 2.0 RFC. Could someone grant
> the wiki user amodliszewski the necessary karma?
>
> Thanks in advance.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Wiki RFC karma request

[Joe Watkins]

Hi Paul,

Thanks for you interest in contributing to PHP, the necessary karma has
been granted to you.

Cheers
Joe

On Wed, 6 Feb 2019 at 11:26, Paul Crovella  wrote:

> I'd like to do some work on a Partial Function Application RFC. Could
> someone grant the wiki user pcrov the necessary karma?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] VOTE abolish narrow margins

[Joe Watkins]

Morning all,

As promised, abolish narrow margins is now open for voting:

https://wiki.php.net/rfc/abolish-narrow-margins

Cheers
Joe

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Dmitry, Nikita,

I've cleaned that up to read "changes to PHP" rather than talking about
merges, apologies for the confusion, just used the wrong words.

To re-iterate what Nikita said, this is not about changing what requires an
RFC, and not about forcing every change to require an RFC; We're all very
aware that there is an almost constant stream of minor improvements
committed by core maintainers that don't require RFC, and this RFC does not
seek to stand in your way.

Cheers
Joe

On Wed, 6 Feb 2019 at 17:31, Nikita Popov  wrote:

> On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov  wrote:
>
>>
>>
>> On 2/6/19 11:50 AM, Nikita Popov wrote:
>> > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins  wrote:
>> >
>> >> Afternoon internals,
>> >>
>> >> Some time ago I brought up for discussion:
>> >> https://wiki.php.net/rfc/abolish-narrow-margins
>> >>
>> >> I intend to bring this up for vote in the next few days.
>> >>
>> >> Cheers
>> >> Joe
>> >>
>> >
>> > After one day of heated discussion this thread has died down again. I'd
>> > like to make sure that there are no further concerns here before this
>> goes
>> > to vote.
>> >
>> > Most of the discussion here has been around the question of whether or
>> not
>> > this should be part of Zeev's RFC (and it doesn't look like we're going
>> to
>> > agree on that one), but there has been little further discussion of the
>> > proposal itself. I guess that means it's fairly uncontroversial.
>> >
>> > As far as I can see the only difference between this proposal and Zeev's
>> > (as far as voting margins are concerned), is that this RFC requires a
>> 2/3
>> > majority, while Zeev's proposal excludes "PHP Packaging Decisions" and
>> only
>> > requires a simple majority for them.
>> >
>> > There has been some brief discussion about this, with the following mail
>> > from Stas:
>> >
>> >> 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/3 requirement would be suspect anyway. RFCs can have parts - "whether
>> >> we do it" and "how exactly we do it" - the former would be 2/3
>> >> requirement, the latter can be simple plurality even - e.g. if we
>> decide
>> >> to have an extension for libfoobar, that should have 2/3 vote, but then
>> >> decision between whether to name it foobar or barfoo can be decided by
>> >> majority or plurality.
>> >
>> > And Zeev's response:
>> >
>> >> I think we do.  There are decisions where a 2/3 majority requirement
>> makes
>> >> no sense, as the vote itself is about a choice between two options that
>> > are
>> >> on the table, as opposed to deciding whether to do something or not.
>> >> There aren't many such cases, but when they do occur - they tend to be
>> >> important.
>> >>
>> >> The most obvious case I have in mind is that of the choice between PHP
>> 6
>> >> and 7.  It doesn't expose us to any future commitments, doesn't change
>> the
>> >> language - it's arguably almost a marketing decision.  Similarly, if we
>> >> decide to change our release schedule, I don't see why that should
>> require
>> >> a 2/3 majority.  The 'bias for the status quo', which is the main
>> reason
>> > we
>> >> have the super majority requirement to begin with, doesn't really play
>> a
>> >> role here - as it bears no long term commitment.
>> >
>> > I'll add my own response here. I agree with Stas that it is preferable
>> to
>> > have a single voting procedure and don't think that "packaging
>> decisions"
>> > should be special cased. This is not just to in the interest of having
>> > simple rules, but also because I disagree with the premise that
>> packaging
>> > decisions are somehow less important than changes to PHP or do not have
>> > future commitments. For example, extending support for a release by
>> > multiple years (a question that will probably come up for PHP 7.4), is a
>> > quite serious commitment of resources that should not be decided on a
>> > narrow margin.
>> >
>> > More importantly, while our past RFCs in the area of "packaging" have
>> not
>&

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

e original native-tls patch that was
proposed some time ago for PHP 5, subsequently Anatol had to do all the
heavy lifting, I understand it very well, but I'm not able to confidently
develop on Windows, just like you, I'm not that familiar with Windows.
Again, fixing these things are going to take time, and the effort of many
of us.

Time and commitment, is all I am asking for, without those my confidence
has evaporated, I'm sorry to say.

Cheers
Joe






On Fri, 15 Feb 2019 at 09:06, Dmitry Stogov  wrote:

> Hi,
>
> On 2/14/19 5:22 PM, Joe Watkins wrote:
> > Morning all,
> >
> > This idea of an experimental feature as complex as a JIT is dangerous. It
> > is not finished, and dmitry has said he's not willing to put more time
> into
> > until it's merged. That's his prerogative, and it is ours to say that we
> > don't want unfinished software that only one or two people really
> > understand in PHP. All of the rest of internals need all of the time
> > between now and PHP 8 to educate ourselves on this so that we function as
> > well as we do now when it comes to finding and fixing bugs, and pushing
> PHP
> > forward.
>
> Few years ago I was claimed for development PHPNNG privately, but that
> time we delivered to @internals almost completed solution. Now you don't
> like the solution, because it's incomplete in your opinion (ZTS support,
> etc), and the development makes troubles...
>
> If you are interested in ZTS, you may invest time in implementation of
> the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
> if you start, because I may find time myself.
>
> I told, I'm not going to do any active JIT development at this point.
> Why to waste time, if it's not going to be accepted...
> However, I keep it in sync with master and PHP-7.4, fix reported
> problems, respond to code review comments, etc (just check git commits
> history).
>
> In last email I asked for ideas for RFC improvement (like notes about
> unsupported ZTS). May be it makes sense to add cons/pros for additional
> PHP-7.4 proposal. May be write something more clear (I'm not a native
> speaker).
>
> But this "a bit toxic" discussion, at least, steals time from
> constructive things.
>
> Joe, please, don't take anything personally.
> Despite I wrote above, I appreciate your involvement in PHP development
> and respect your opinion regarding JIT, ZTS. etc.
>
> Thanks. Dmitry.
>
>
> > Merging the JIT into 7.4 puts a brick wall in the way of progress
> > that none of us have the tools to climb over.
> >
> > I hear the argument about wanting to test, but anyone with sufficient
> > expertise to test the JIT is capable of building the branch available on
> > github, we do not need to push out an incomplete product to the entire
> > world for the sake of that handful of individuals who will actually test.
> >
> > I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
> > current form, and would ask everyone to please think very carefully about
> > it, prior to supporting it.
> >
> > Thanks
> > Joe
> >
> >
> > On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks 
> > wrote:
> >
> >> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas <
> nicolas.grekas+...@gmail.com
> >>> :
> >>
> >>>> [...] I think that whether or not we include it in 7.4
> >>>> is a tactical decision (and I'm not sure myself where I stand on it),
> >>> but I
> >>>> do think there's a reasonable case for both directions.
> >>>>
> >>>
> >>> If I may add some voice to Zeev's arguments, being able to play with
> JIT
> >> as
> >>> early as possible would allow the community to experiment using PHP in
> >>> areas where it doesn't fit right now. Having to wait 2 more years to
> >>> discover that maybe it's useful to build some new libraries could be a
> >>> waste of time at the tactical level (there are other technologies
> around
> >>> that move fast also :) )
> >>>
> >>> Not to detract from the technical challenges of moving in this
> direction,
> >>> of course.
> >>> Just my 2cts from a "userland" guy :)
> >>>
> >>> Nicolas
> >>>
> >>
> >> Hello everyone,
> >>
> >> I agree with this sentiment and the general idea of shipping JIT as
> >> experimental in 7.4 and required to build with a configure flag.
> >> master for 8.0 is going to contain much more and be more unstable and
> not
> >> practical for testing what JIT can do at that point due to all other
> >> features and improvements going into it like additional optimizations
> and
> >> platform support.
> >> It will give me, as a userland developer, a platform where I can
> actually
> >> play with it early and on a stable platform. And I understand what I'm
> >> doing at that point.
> >>
> >> --
> >> Arvīds Godjuks
> >>
> >> +371 26 851 664
> >> arvids.godj...@gmail.com
> >> Skype: psihius
> >> Telegram: @psihius https://t.me/psihius
> >>
> >
>

[PHP-DEV] Re: ZTS improvement idea

[Joe Watkins]

Morning all,

I'm very pleased to see effort going into this, and the resulting ideas.

I don't have anything to add about the implementation.

Since most people are not interested in ZTS, there aren't going to be many
voices pushing you to actually make changes, so I want to be that voice.

The ZTS build is very commonly used in Windows today, and I'm sure everyone
doing that would appreciate you making these changes as soon as reasonable,
which looks like 7.4, beyond that before we can talk about developing JIT
support in Windows, ZTS support must be in place.

Thanks for the effort so far.

Cheers
Joe

On Wed, 13 Feb 2019 at 10:02, Nikita Popov  wrote:

> On Wed, Feb 13, 2019 at 9:26 AM Dmitry Stogov  wrote:
>
>> Hi,
>>
>>
>> After JIT+ZTS related discussion with Joe and Bob, and some related
>> analyzes.
>>
>> I came to more or less formed design idea and described it at
>> https://wiki.php.net/zts-improvement
>>
>> This is not an RFC and I'm not sure, if I like to implement TSRM changes
>> myself now.
>>
>>
>> Comments are welcome.
>>
>
> Hi Dmitry,
>
> Thanks for looking into this issue. As a possible alternative I would like
> to suggest the use of ZEND_TLS (__thread) for the EG/CG/BG etc globals on
> Linux (on Windows this is not possible due to DLL linkage restrictions).
> __thread generates very good code (single load over %fs segment with
> constant address) if the global is defined and used in an executable. I'm
> not sure what kind of code it generates when TLS is declared in an
> executable and used in a shared object, but as direct access from
> extensions to the engine globals shouldn't be common, it's probably okay
> even if it uses __tls_get_addr.
>
> Nikita
>

Re: [PHP-DEV] proper anonymous classes?

[Joe Watkins]

What you describe is first class support for classes, nothing much to do
with anonymous classes.

On Wed, 13 Feb 2019, 09:01 Rasmus Schultz  The fact that the anonymous class syntax defines a class *and* immediately
> constructs an instance is quite annoying.
>
> For one, this is quite incompatible with DI containers' ability to resolve
> constructor arguments.
>
> Lets say you DI container can register a named component by merely
> referencing a class that uses constructor injection - so lets say this
> works:
>
> class MyController {
> public function __construct(MyService $service) {
> // ...
> }
> }
>
> $container->register("my-controller", MyController::class);
>
> Now I want to register an anonymous class, for example as part of an
> integration test-suite, which is common enough:
>
> $container->register("my-controller", new class {
> public function __construct(MyService $service) {
> // ...
> }
> });
>
> This doesn't work, because you're expected to actually pass the constructor
> arguments immediately - because you can only define an anonymous class
> while immediately creating an instance.
>
> What I really want is just an anonymous class - not an instance, so:
>
> $container->register("my-controller", class {
> public function __construct(MyService $service) {
> // ...
> }
> });
>
> The question is, what would a class expression without the new keyword
> evaluate to?
>
> Since we normally reference classes with just a class-name, I guess I'd
> expect a string, like you'd get from the ::class constant.
>
> Any hope for something like that?
>

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

Morning all,

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing PHP
forward. Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

Thanks
Joe


On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks 
wrote:

> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas  >:
>
> > > [...] I think that whether or not we include it in 7.4
> > > is a tactical decision (and I'm not sure myself where I stand on it),
> > but I
> > > do think there's a reasonable case for both directions.
> > >
> >
> > If I may add some voice to Zeev's arguments, being able to play with JIT
> as
> > early as possible would allow the community to experiment using PHP in
> > areas where it doesn't fit right now. Having to wait 2 more years to
> > discover that maybe it's useful to build some new libraries could be a
> > waste of time at the tactical level (there are other technologies around
> > that move fast also :) )
> >
> > Not to detract from the technical challenges of moving in this direction,
> > of course.
> > Just my 2cts from a "userland" guy :)
> >
> > Nicolas
> >
>
> Hello everyone,
>
> I agree with this sentiment and the general idea of shipping JIT as
> experimental in 7.4 and required to build with a configure flag.
> master for 8.0 is going to contain much more and be more unstable and not
> practical for testing what JIT can do at that point due to all other
> features and improvements going into it like additional optimizations and
> platform support.
> It will give me, as a userland developer, a platform where I can actually
> play with it early and on a stable platform. And I understand what I'm
> doing at that point.
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>

Re: [PHP-DEV] Re: ZTS improvement idea

[Joe Watkins]

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.

We are talking about merging a thing that has the ability to make some
maths faster, at huge cost to the project, in two days I wrote a new
extension called parallel that can make *any* code faster if you have the
cores, which we all do, without complicating anything, and without cost.
Just a bit of thinking necessary.

I don't object to the JIT at all, but without zts it's a non starter for
me. The fact that there are easy improvements that could be done for ZTS
that we seem to being held to ransom for is just awful.

I wish more people would really think ...

https://gist.github.com/krakjoe/254897be71d23b5d5ac2d436f52e8d7d

Cheers
Joe

On Thu, 14 Feb 2019, 16:59 Rowan Collins  On Thu, 14 Feb 2019 at 15:47, 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?
> >
> > windows.php.net:
> >
> > | With Apache you have to use the Thread Safe (TS) versions of PHP.
> >
> >
>
> Ah, that makes sense; the only Apache MPM supported on Windows is
> mpm_winnt, which is thread-based:
> http://httpd.apache.org/docs/2.4/mod/mpm_winnt.html
>
> Again, this only makes sense if using server modules (mod_php); anyone
> using FastCGI will presumably be unaffected.
>
>
> All that being said, it would be nice if ZTS became more mainstream, so
> more people had access to userland threading / parallel processing
> extensions.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Re: ZTS improvement idea

[Joe Watkins]

Packages such as xampp, which are very widely used, bundle a thread safe
interpreter.

It's a fact that ZTS is important on Windows.

Cheers
Joe

On Thu, 14 Feb 2019 at 16:22, 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
> > >
> >
> > Any idea why?
> >
>
>
> https://windows.php.net/ currently recommends using an NTS build with
> FastCGI, but there is (or was?) also an ISAPI module, i.e. the IIS
> equivalent of Apache mod_php.
>
> I think that requires / required ZTS, so that may be where the perception
> of "thread-safety is important for Windows users" comes from.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Morning Dmitry,

I've cleaned up the proposal section to refer to the normative text
section, but it remains to make clear that we are applying these rules to
all RFCs (including policy amendments).

Cheers
Joe

On Wed, 6 Feb 2019 at 22:12, Dmitry Stogov  wrote:

>
>
> On 2/6/19 8:28 PM, Joe Watkins wrote:
> > Afternoon Dmitry, Nikita,
> >
> > I've cleaned that up to read "changes to PHP" rather than talking about
> > merges, apologies for the confusion, just used the wrong words.
> >
> > To re-iterate what Nikita said, this is not about changing what requires
> > an RFC, and not about forcing every change to require an RFC; We're all
> > very aware that there is an almost constant stream of minor improvements
> > committed by core maintainers that don't require RFC, and this RFC does
> > not seek to stand in your way.
>
> The "Normative text" section looks clear now.
> I would remove all the rest of the "Proposal" section, assuming that
> it's reflected in the "Normative text", anyway.
>
> Additional note (unrelated to this RFC, but related to RFC process).
> It would be great to define some formal procedure of approval of RFC
> implementation patches.
> - When a patch is required and good enough, to turn RFC into voting?
> - When a patch of accepted RFC may (or may not) be merged?
>
> Currently, this procedure is completely informal.
>
> Thanks. Dmitry.
>
>
>
>
> > Cheers
> > Joe
> >
> > On Wed, 6 Feb 2019 at 17:31, Nikita Popov  > <mailto:nikita@gmail.com>> wrote:
> >
> > On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov  > <mailto:dmi...@zend.com>> wrote:
> >
> >
> >
> > On 2/6/19 11:50 AM, Nikita Popov wrote:
> >  > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins
> > mailto:krak...@gmail.com>> wrote:
> >  >
> >  >> Afternoon internals,
> >  >>
> >  >> Some time ago I brought up for discussion:
> >  >> https://wiki.php.net/rfc/abolish-narrow-margins
> >  >>
> >  >> I intend to bring this up for vote in the next few days.
> >  >>
> >  >> Cheers
> >  >> Joe
> >  >>
> >  >
> >  > After one day of heated discussion this thread has died down
> > again. I'd
> >  > like to make sure that there are no further concerns here
> > before this goes
> >  > to vote.
> >  >
> >  > Most of the discussion here has been around the question of
> > whether or not
> >  > this should be part of Zeev's RFC (and it doesn't look like
> > we're going to
> >  > agree on that one), but there has been little further
> > discussion of the
> >  > proposal itself. I guess that means it's fairly
> uncontroversial.
> >  >
> >  > As far as I can see the only difference between this proposal
> > and Zeev's
> >  > (as far as voting margins are concerned), is that this RFC
> > requires a 2/3
> >  > majority, while Zeev's proposal excludes "PHP Packaging
> > Decisions" and only
> >  > requires a simple majority for them.
> >  >
> >  > There has been some brief discussion about this, with the
> > following mail
> >  > from Stas:
> >  >
> >  >> 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/3 requirement would be suspect anyway. RFCs can have parts
> > - "whether
> >  >> we do it" and "how exactly we do it" - the former would be
> 2/3
> >  >> requirement, the latter can be simple plurality even - e.g.
> > if we decide
> >  >> to have an extension for libfoobar, that should have 2/3
> > vote, but then
> >  >> decision between whether to name it foobar or barfoo can be
> > decided by
> >  >> majority or plurality.
> >  >
> >  > And Zeev's response:
> >  >
> >  >> I think we do.  There are decisions where a 2/3 majority
> > requirement m

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

Morning Dmitry, and internals,

This is marvellous stuff, truly brilliant. I particularly appreciate the
non-intrusive approach of setting jit'd code as the opcode handler, this
makes life a little easier for hacky extension authors, I think.

As others have said:

  I don't like the idea of omitting to support windows, less worried about
fancy architectures.
  I'm not keen on the idea that there is no way to debug the code this
generates outside of GDB, and I'm not sure how useful gdb will be: I've
tried to debug JIT'd code in that before and it doesn't do so well, but I
could easily have been doing it wrong. I'd be very happy to be corrected
about this ?
  I'm not keen on the idea of merging this into 7.4, for various reasons
that don't need to be repeated.

Bottom line though, I love it, it's brilliant, and look forward to PHP 8.

Thank you, Dmitry.

Cheers
Joe


On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  wrote:

>
>
> On 2/1/19 3:29 AM, Larry Garfield wrote:
> > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
> >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  wrote:
> >>> 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 counterpart have, it is still a very important
>  development platform. Many developers develop on Windows and deploy on
>  a Unix based system, being unable to test such an important feature in
>  a development environment is also a large question mark.
> >>>
> >>> As long as we can agree that very few actually *deploy *on Windows, I
> >>> think
> >>> we're on solid grounds.
> >>> As the JIT implementation is likely to have at least *some* significant
> >>> differences compared to Linux, I'm not sure what testing it on Windows
> >>> would give you.  JIT is supposed to be entirely transparent, and the
> >>> performance characteristics - as well as the bug patterns - are likely
> to
> >>> be quite different on Linux vs. Windows, at least in many cases.
> >>> Is it really that important to have?
> >>>
> >>> 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 scarcely found on production Windows servers, and JIT is a
> >>> predominantly production feature.
> >>>
> >>> I'm personally interested in taking a look at it (and I'm certain
> >>>
>  Anatol does too), but simply dismissing is a no-go for me.
> >>>
> >>> It'd be interesting to evaluate the cost associated with supporting
> >>> Windows.  Bare in mind, we're proposing to vote on this as a production
> >>> feature for PHP 8 - which realistically means almost two years from now
> >>> *at
> >>> the earliest*.  I'm sure we'd have Windows support a lot sooner than
> that
> >>> if we decide that it's a must have.  I agree with Nikita that the key
> >>> question is in fact, do we or do we not want to introduce JIT in - with
> >>> the
> >>> main question being the maintenance cost.  Let's tackle this question
> >>> first, otherwise - why send Dmitry (and maybe others) for doing more
> work
> >>> (Windows support) if we are likely to flush it all down the toilet?
> >>>
> >> Maybe we're the only ones, but we run production PHP on Windows. I have
> no
> >> issues with the idea of not initially having support for Windows. I can
> >> probably even live with never having support for Windows - provided
> that we
> >> don't find ourselves in a situation like Nikita mentioned where features
> >> start getting developed in PHP instead of C and require JIT in order to
> >> function.
> >
> > Question from a non-compiler-engineer: Could we end up in a situation
> where
> > future language features (in 8.3 or something) are only performant on
> JIT-
> > enabled platforms?  I know there were some RFCs rejected in the past on
> the
> > grounds that they involved too many runtime checks (and thus a
> performance
> > hit); if it were possible for a JIT to optimize some of those away, it
> might
> > make the cost acceptable.  However, if a JIT only works on some systems
> that
> > might widen the gap between have- and have-not platforms.
>
> I think, JIT only approach doesn't make a lot of sense for PHP, with one
> of the most fast VM. And this is a trend. Even V8, starting from JIT
> only, switched back to VM+JIT.
>
> Thanks. Dmitry.
>
> >
> > Is that a concern, or am I making things up?  Or, is it a concern but
> we're
> > legit OK with that happening (which is also an entirely valid decision to
> > make)?
> >
> > --Larry Garfield
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Morning Stas, and all,

This discussion was ... a mess, partly my fault, I suppose.

I said I was going to bring it up for voting quickly on the say so of
Nikita, and because it feels urgent to us, you can guess our reasons for
that.

I'm not going to argue back and forth for the next week about the reasons
we think this is important.

In a week, let's say next Friday, to be totally fair, this RFC will go to
vote.

Cheers
Joe

On Fri, 1 Feb 2019 at 06:16, 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 already been delayed numerous times and it is imperative that we
> > prevent that from happening again. Since this issue was first raised, a
>
> That's understandable. But I think if we have an ongoing discussion now,
> waiting until this discussion comes to some conclusion or at least
> giving it some reasonable time to do so is a good thing. Note the
> "reasonable" part - it doesn't mean it should wait another 2 years. But
> if 2+ year old RFC is revived I think it's reasonable to wait a week or
> two with vote. Original margins were meant for situation where somebody
> puts up RFC and immediately proceeds to vote, not for situation where
> RFC lies dormant for 2 years, then revived and immediately proceeds to
> vote without most people even remembering what happened 2 years ago. I
> think in this case it's reasonable to wait a little bit - and I don't
> see a reason why not.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Disable PEAR by default

[Joe Watkins]

+1

On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann  wrote:

> Am 01.02.2019 um 12:27 schrieb Nikita Popov:
> > 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
>
> +1
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] RFC Weakrefs

[Joe Watkins]

Morning internals,

Some time ago I brought this up for discussion, and last night was reminded
of it's existence, and so this morning rebased and reworked the patch a
little based on the feedback I got back then.

Since it was long ago, and there's no particular rush, I don't intend to
open voting until the current policy adjustment RFC's are resolved, but
wanted to give everyone a heads up and ask for any feedback you may have at
this time.

https://wiki.php.net/rfc/weakrefs

Cheers
Joe

[PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Afternoon Christoph,

I can't really think of another name ... it's ... a weakref ...

Probably using the PHP namespace makes most sense.

Cheers
Joe

On Sun, 3 Feb 2019 at 18:40, Christoph M. Becker  wrote:

> On 02.02.2019 at 09:35, Joe Watkins wrote:
>
> > Some time ago I brought this up for discussion, and last night was
> reminded
> > of it's existence, and so this morning rebased and reworked the patch a
> > little based on the feedback I got back then.
> >
> > Since it was long ago, and there's no particular rush, I don't intend to
> > open voting until the current policy adjustment RFC's are resolved, but
> > wanted to give everyone a heads up and ask for any feedback you may have
> at
> > this time.
> >
> > https://wiki.php.net/rfc/weakrefs
>
> Overall I like this.  Thanks!
>
> However, calling this class WeakRef would introduce a potential BC
> break, and would be a particular issue regarding the PHP manual, which
> does not allow to document two classes with exactly the same name.
>
> Even if Etienne would officially cease the further development of
> PECL/Weakref[1], having a class with the same name appears to be
> confusing at best.
>
> Maybe another name should be chosen for the class?  Or maybe we should
> finally introduce the \PHP namespace?
>
> [1] <https://pecl.php.net/package/Weakref>
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Updated patch, name is WeakReference.

Cheers
Joe

On Sun, 3 Feb 2019 at 19:39, Joe Watkins  wrote:

> Does that solve the problem for you Christoph ?
>
> Cheers
> Joe
>
> On Sun, 3 Feb 2019 at 19:08, Robert Korulczyk  wrote:
>
>>
>> > I can't really think of another name ... it's ... a weakref ...
>>
>> It is actually "weak reference", so why not WeakReference?
>>
>>
>> Regards,
>> Robert Korulczyk
>>
>

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Already taken care of :)

On a side note, at what point do we remove stuff from the manual/pecl, the
weakref is extension is dead, can't work with current versions of PHP, and
there was never a stable release ?

I'm not even sure we have a mechanism to delete stuff from pecl ... there's
probably quite a lot of junk on there ...

Cheers
Joe

On Sun, 3 Feb 2019 at 19:56, Christoph M. Becker  wrote:

> On 03.02.2019 at 19:39, Joe Watkins wrote:
>
> > Does that solve the problem for you Christoph ?
>
> Yes, calling the class WeakReference would be fine for me.
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Does that solve the problem for you Christoph ?

Cheers
Joe

On Sun, 3 Feb 2019 at 19:08, Robert Korulczyk  wrote:

>
> > I can't really think of another name ... it's ... a weakref ...
>
> It is actually "weak reference", so why not WeakReference?
>
>
> Regards,
> Robert Korulczyk
>

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Joe Watkins]

Just a quick note ...

I should say that bug fixes should not require an RFC at all, but the line
between bug, quick fix and feature is blurry. Sometimes it is necessary to
gather consensus and voting is the most effective way we have to do that.

Cheers
Joe

On Sat, 2 Feb 2019 at 18:13, Joe Watkins  wrote:

> Hi Legale, internals,
>
> > I want to say that even a small and fairly
> simple code change,
> which I proposed to push through the bureaucracy, was difficult.
>
> This, I am afraid is all too common. Many many times, while working
> through github issues, I will be uncomfortable with making a merge for
> someone without input from internals. I would tell that person to start a
> discussion on internals and they would be flat ignored, their change dead
> in the water, and their reason to continue contributing evaporates.
>
> I think these proposals have a chance of reducing the occurrences of those
> situations: We all know that for less interesting topics, vote time is
> crunch time and that is when internals pays attention. If there is no
> necessity to wait for X weeks between proposing a change that nobody really
> has a desire to discuss, and opening a vote, that person can move forward
> quickly, we get our bug/quick fix faster, everyone is happy, especially
> that contributor who feels valued, and who feels that PHP's development
> process is geared toward actual development of PHP.
>
> Cheers
> Joe
>
> On Sat, 2 Feb 2019 at 18:02, Legale Legage 
> wrote:
>
>> Hello, internals.
>> I am with you recently. But as a person with a fresh look, let me insert
>> my
>> 5 penny coin.
>> About half a year ago, I knew about the C language only that such a
>> language exists.
>> The reason I decided to contribute is curiosity. So I'm probably not as
>> motivated
>> as some of other internals. I want to say that even a small and fairly
>> simple code change,
>> which I proposed to push through the bureaucracy, was difficult. So If RFC
>> process
>> becomes more difficult this "road" will be closed for some sort of random
>> people like me.
>> I hope this doesn't happen.
>>
>> Best regards, Ruslan
>>
>> On Sat, 2 Feb 2019 at 17:24, Nikita Popov  wrote:
>>
>> > Hi internals,
>> >
>> > After discussing the topic with a number of current and former
>> > contributors, I feel that the workflow & voting RFC currently under
>> > discussion is moving us in the wrong direction. I will not comment on
>> the
>> > rather questionable proposed changes to voting eligibility, as these are
>> > already extensively discussed in the RFC thread.
>> >
>> > The remainder of the workflow & voting RFC is mostly concerned with
>> > defining stricter rules and more rigid procedures for the RFC process.
>> It
>> > increases the amount of bureaucracy and overhead involved in the RFC
>> > process, making the RFC processes even less suitable for smaller changes
>> > than it already is.
>> >
>> > The proposal I would like to present in the following is not my own
>> idea,
>> > it has been suggested by Anthony Ferrara. Because I found the idea very
>> > compelling, I'm presenting it to the list now.
>> >
>> > ---
>> >
>> > Instead of making the RFC process more complex and rigid, we should
>> > simplify and streamline it. The RFC process is reduced to only two
>> rules:
>> >
>> > 1. All primary RFC votes require a 2/3 majority, while secondary votes
>> > resolving implementation details may use a simple majority. (This is
>> > already proposed in the voting margins RFC, so discussion about this
>> point
>> > should be directed into the corresponding RFC thread.)
>> >
>> > 2. All RFCs must have a voting period of at least 14 days, announced in
>> a
>> > separate [VOTE] thread.
>> >
>> > ---
>> >
>> > That's it. More notable than the rules itself are probably the two main
>> > omissions:
>> >
>> > 1. There is no required discussion period. However, if an RFC vote is
>> > opened without leaving enough time for discussion, then voters can and
>> > should vote the RFC down on the grounds of insufficient discussion.
>> >
>> > The motivation for not having a fixed discussion period (but a longer
>> > minimum voting period) is that RFCs come in many different forms and
>> sizes.
>> > Some RFCs are long and complex (such as the recent typed properties RFC)
>> > and require more time for an adequa

Re: [PHP-DEV] AppVeyor timeouts -- Migrate to Azure Pipelines?

[Joe Watkins]

Hi Nikita,

I can't be helpful here at all, because (shamefully) allergic to and bad at
windows, and no experience at all with azure.

But I would really like our CI to be restored to a thing that's useful,
instead of running two jobs on travis, and more or less nothing on av (most
of the time).

I remember having CI on travis for many configurations, including the ones
we actually develop with. Now we have two configurations and they don't
include no-zts-dbg which is what most internal devs are actually running.

Anything that restores anything like that former configuration, I'm a
huge +1 on ...

Anything that means we can run a useful windows CI, even if we can't move
any of the jobs that should be on travis over to Azure, I'm still a +1 on
...

Anything that means we have a mac build, the same +1 ...

Cheers
Joe

On Sat, 2 Feb 2019 at 19:38, Stanislav Malyshev  wrote:

> Hi!
>
> > I just learned about the Azure Pipelines (
> > https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
> > which offers open source projects 10 parallel builds with unlimited
> > minutes. Assuming there's no other catch here, it might be worthwhile to
> > migrate our Windows CI jobs to Azure Pipelines.
>
> Maybe also get Linux and macOS jobs there? We currently don't have CI
> for macOS at all, AFAIK, and having different Linux environment probably
> won't hurt either.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Joe Watkins]

Afternoon Nikita, internals,

In stark contrast to the proposals being made to make contributing to PHP
more complex, slower, and burdened with bureaucracy: These are elegant
proposals that I think will invite new contributors to join our ranks,
which we no doubt need. They will allow current contributors to work faster
on PHP without reducing the quality of their work or the input the rest of
internals has on their contributions. I would hope that it would reduce the
number of RFC that sit on the Wiki for years at a time also, but this is
only my hope.

While these are quite drastic changes, let us try to resist a knee jerk
response to them.

>From me, it's +1

Cheers
Joe

On Sat, 2 Feb 2019 at 17:24, Nikita Popov  wrote:

> Hi internals,
>
> After discussing the topic with a number of current and former
> contributors, I feel that the workflow & voting RFC currently under
> discussion is moving us in the wrong direction. I will not comment on the
> rather questionable proposed changes to voting eligibility, as these are
> already extensively discussed in the RFC thread.
>
> The remainder of the workflow & voting RFC is mostly concerned with
> defining stricter rules and more rigid procedures for the RFC process. It
> increases the amount of bureaucracy and overhead involved in the RFC
> process, making the RFC processes even less suitable for smaller changes
> than it already is.
>
> The proposal I would like to present in the following is not my own idea,
> it has been suggested by Anthony Ferrara. Because I found the idea very
> compelling, I'm presenting it to the list now.
>
> ---
>
> Instead of making the RFC process more complex and rigid, we should
> simplify and streamline it. The RFC process is reduced to only two rules:
>
> 1. All primary RFC votes require a 2/3 majority, while secondary votes
> resolving implementation details may use a simple majority. (This is
> already proposed in the voting margins RFC, so discussion about this point
> should be directed into the corresponding RFC thread.)
>
> 2. All RFCs must have a voting period of at least 14 days, announced in a
> separate [VOTE] thread.
>
> ---
>
> That's it. More notable than the rules itself are probably the two main
> omissions:
>
> 1. There is no required discussion period. However, if an RFC vote is
> opened without leaving enough time for discussion, then voters can and
> should vote the RFC down on the grounds of insufficient discussion.
>
> The motivation for not having a fixed discussion period (but a longer
> minimum voting period) is that RFCs come in many different forms and sizes.
> Some RFCs are long and complex (such as the recent typed properties RFC)
> and require more time for an adequate discussion. Other RFCs are simple and
> of limited scope (such as an extension function addition) and do not
> require extensive discussion.
>
> While a two week discussion period should remain a good guideline for
> language-related RFCs, it is up to the RFC author to decide when opening an
> RFC vote is appropriate. This will depend both on the scope of the RFC
> itself and the activity of the discussion. (It is an unfortunate fact that
> many RFCs receive their first meaningful feedback during the voting
> period.)
>
> 2. There is no moratorium period after an RFC vote fails. If you think that
> you have made significant progress on an RFC and resolved the issues that
> made the previous vote fail, you can give it another shot at any time,
> without having to wait out some fixed period.
>
> A failed vote does not (necessarily) mean that a feature is not wanted. It
> is quite common for significant changes to fail on first vote, due to
> issues in the initial proposal. A failed vote should not be a
> discouragement, but a motivation to address problems expressed during
> discussion or voting.
>
> It should go without saying that if you restart a failed RFC vote without
> making substantial changes to the RFC, the result is unlikely to change in
> your favor, and that continued misbehavior might be seen as spam.
>
> ---
>
> Essentially, this is about making the RFC process more suitable for changes
> small and large, and empowering both RFC authors and the voter base to make
> decisions that are appropriate for each RFC.
>
> What do you think?
>
> Regards,
> Nikita
>

Re: [PHP-DEV] phpenmod/phpdismod

[Joe Watkins]

Hi Legale,

In general we leave the packaging of PHP to the packaging experts. So I
doubt if there's much need to include these in php-src, but let's see what
others have to say ?

Cheers
Joe

On Sat, 2 Feb 2019 at 20:24, Legale Legage  wrote:

> Hello, internal.
>
> I want to propose including to the bundle phpenmod/phpdismod scripts. These
> scripts are included to the standard deb/rpm packages. What do you think
> about including them to the bundle?
>
> If the idea is worthwhile, I will make the RFC.
>
> Saluti, Ruslan
>

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Joe Watkins]

Hi Legale, internals,

> I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.

This, I am afraid is all too common. Many many times, while working through
github issues, I will be uncomfortable with making a merge for someone
without input from internals. I would tell that person to start a
discussion on internals and they would be flat ignored, their change dead
in the water, and their reason to continue contributing evaporates.

I think these proposals have a chance of reducing the occurrences of those
situations: We all know that for less interesting topics, vote time is
crunch time and that is when internals pays attention. If there is no
necessity to wait for X weeks between proposing a change that nobody really
has a desire to discuss, and opening a vote, that person can move forward
quickly, we get our bug/quick fix faster, everyone is happy, especially
that contributor who feels valued, and who feels that PHP's development
process is geared toward actual development of PHP.

Cheers
Joe

On Sat, 2 Feb 2019 at 18:02, Legale Legage  wrote:

> Hello, internals.
> I am with you recently. But as a person with a fresh look, let me insert my
> 5 penny coin.
> About half a year ago, I knew about the C language only that such a
> language exists.
> The reason I decided to contribute is curiosity. So I'm probably not as
> motivated
> as some of other internals. I want to say that even a small and fairly
> simple code change,
> which I proposed to push through the bureaucracy, was difficult. So If RFC
> process
> becomes more difficult this "road" will be closed for some sort of random
> people like me.
> I hope this doesn't happen.
>
> Best regards, Ruslan
>
> On Sat, 2 Feb 2019 at 17:24, Nikita Popov  wrote:
>
> > Hi internals,
> >
> > After discussing the topic with a number of current and former
> > contributors, I feel that the workflow & voting RFC currently under
> > discussion is moving us in the wrong direction. I will not comment on the
> > rather questionable proposed changes to voting eligibility, as these are
> > already extensively discussed in the RFC thread.
> >
> > The remainder of the workflow & voting RFC is mostly concerned with
> > defining stricter rules and more rigid procedures for the RFC process. It
> > increases the amount of bureaucracy and overhead involved in the RFC
> > process, making the RFC processes even less suitable for smaller changes
> > than it already is.
> >
> > The proposal I would like to present in the following is not my own idea,
> > it has been suggested by Anthony Ferrara. Because I found the idea very
> > compelling, I'm presenting it to the list now.
> >
> > ---
> >
> > Instead of making the RFC process more complex and rigid, we should
> > simplify and streamline it. The RFC process is reduced to only two rules:
> >
> > 1. All primary RFC votes require a 2/3 majority, while secondary votes
> > resolving implementation details may use a simple majority. (This is
> > already proposed in the voting margins RFC, so discussion about this
> point
> > should be directed into the corresponding RFC thread.)
> >
> > 2. All RFCs must have a voting period of at least 14 days, announced in a
> > separate [VOTE] thread.
> >
> > ---
> >
> > That's it. More notable than the rules itself are probably the two main
> > omissions:
> >
> > 1. There is no required discussion period. However, if an RFC vote is
> > opened without leaving enough time for discussion, then voters can and
> > should vote the RFC down on the grounds of insufficient discussion.
> >
> > The motivation for not having a fixed discussion period (but a longer
> > minimum voting period) is that RFCs come in many different forms and
> sizes.
> > Some RFCs are long and complex (such as the recent typed properties RFC)
> > and require more time for an adequate discussion. Other RFCs are simple
> and
> > of limited scope (such as an extension function addition) and do not
> > require extensive discussion.
> >
> > While a two week discussion period should remain a good guideline for
> > language-related RFCs, it is up to the RFC author to decide when opening
> an
> > RFC vote is appropriate. This will depend both on the scope of the RFC
> > itself and the activity of the discussion. (It is an unfortunate fact
> that
> > many RFCs receive their first meaningful feedback during the voting
> > period.)
> >
> > 2. There is no moratorium period after an RFC vote fails. If you think
> that
> > you have made significant progress on an RFC and resolved the issues that
> > made the previous vote fail, you can give it another shot at any time,
> > without having to wait out some fixed period.
> >
> > A failed vote does not (necessarily) mean that a feature is not wanted.
> It
> > is quite common for significant changes to fail on first vote, due to
> > issues in the initial proposal. A failed vote should not be a
> > discouragement, but a motivation 

[PHP-DEV] RFC: Abolish Narrow Margins

[Joe Watkins]

Afternoon internals,

Some time ago I brought up for discussion:
https://wiki.php.net/rfc/abolish-narrow-margins

I intend to bring this up for vote in the next few days.

Cheers
Joe

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

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, prematurely, it makes perfect sense to
discuss margins independently, and I intend to do so. Your opinion will be
taken into consideration when you cast your vote.

I do insist, and will not be waiting two weeks, unless you agree to delay
the JIT RFC until this issue is resolved.

Cheers
Joe



On Thu, 31 Jan 2019 at 14:07, Zeev Suraski  wrote:

> >-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 to bring this up for vote in the next few days.
>
> Joe,
>
> Given that time that passed since I brought up my wider-scoped RFC, and
> yet haven't pushed it through (some major things were happening on my end,
> as you may have heard...) - I can imagine you're not going to like what I'm
> going to say, but fundamentally - nothing changed.  It still doesn't make
> sense, IMHO, to discuss the margin independently of other questions - even
> if you explicitly mention them as being outside of the scope of the RFC.
>
> Also, given the time that passed and the importance of this, it should
> require a brand new mandatory 2-week discussion period before we go for a
> vote - even if you insist on moving forward with this narrow-scoped RFC.
>
> At the same time, I'd like to finally solicit feedback explicitly on my
> wider-scoped RFC, as I guess we can't wait any longer.  I'll send a
> separate email about that.
>
> Zeev
>
>

[PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon internals,

Some time ago I brought up for discussion:
https://wiki.php.net/rfc/abolish-narrow-margins

I intend to bring this up for vote in the next few days.

Cheers
Joe

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

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
latter.

Let us be clear about the things you are doing:

You pushed FFI into php-src on a simple majority, it had one user, was
incomplete (with leaks), and had zero justification for being included in
php-src - it didn't require any internal API's and can function just fine
as a PECL extension, still you pushed through with the RFC and it was
accepted on a simple majority.

You are now trying to push JIT into php-src on the same slim, clearly
unacceptable majority, and even if you change the majority requirements,
what's worse is you want to include it in a minor version. Once again, this
is an incomplete feature, failing to support the architectures we support
and declaring them unimportant. You are pushing PHP towards a future where
there is effectively a single contributor, possibly two, able to make
changes to Zend+Opcache; You are changing core parts of PHP too fast and
making other contributors, including the maintainers of external tooling
which the ecosystem requires to function, uncomfortable.

I really don't think you have bad intentions, but think our processes are
allowing us to make questionable decisions for the whole project, and this
I intend to resolve, regardless of your next actions, before any more
questionable decisions can be taken.

Cheers
Joe






On Thu, 31 Jan 2019 at 14:38, Zeev Suraski  wrote:

> Joe,
>
>
>
> First, you have to wait an absolute minimum of one week, and arguably two
> weeks, from the point in time you say you intend to move ahead with the RFC
> for a vote.  That’s per the ratified Voting RFC, this really isn’t up for
> the individual RFC author to decide.  It’s clear that an author can’t wake
> up a year after a certain discussion and move directly to a vote, even in
> the poorly written Voting RFC that’s currently in effect.  Given the far
> reaching implications of this particular RFC, it’s pretty clear that this
> shouldn’t be one of the short, 1-week ones, but I guess this is open for
> interpretation (yet another illness of the current Voting RFC that must be
> resolved).
>
>
>
> Re: JIT - I don’t think we should halt the discussion on the RFC, but I do
> think it should require a 2/3 majority – IFF we define the voting rights
> and other topics.  In other words – we can start discussing the merits and
> downsides of the RFC – but should probably wait with the vote itself until
> that’s cleared.
>
>
>
> For the record, I resent the language you used and the mal-intentions you
> attribute to me here.  I’ll leave it at that.
>
>
>
> Zeev
>
>
>
> *From:* Joe Watkins 
> *Sent:* Thursday, January 31, 2019 3:26 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, prematurely, it makes perfect sense to
> discuss margins independently, and I intend to do so. Your opinion will be
> taken into consideration when you cast your vote.
>
>
>
> I do insist, and will not be waiting two weeks, unless you agree to delay
> the JIT RFC until this issue is resolved.
>
>
>
> Cheers
>
> Joe
>
>
>
>
>
>
>
> On Thu, 31 Jan 2019 at 14:07, Zeev Suraski  wrote:
>
> >-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 to bring this up for vote in the next few days.
>
> Joe,
>
> Given that time that passed since I brought up my wider-scoped RFC, and
> yet haven't pushed it through (some major things were happening on my end,
> as you may have heard...) - I can imagine you're not going to like what I'm
> going to say, but fundamentally - nothing changed.  It still doesn't make
> sense, IMHO, to discuss the margin independently of other questions - even
> if you explicitly mention them as being outside of the scope of the RFC.
>
> Also, given the time that passed and the importance of this, it should
> require a brand new mandatory 2-week discussion period before we go for a
> vote - even if you insist on moving forward with this narrow-scoped RFC.
>
> At the same time, I'd like to finally solicit feedback explicitly on my
> wider-scoped RFC, as I guess we can't wait any longer.  I'll send a
> separate email about that.
>
> Zeev
>
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

> I'll happily take your interpretation of it.  No hard feelings.

Thanks, you know I don't have another way of being :)

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.

> I would say that Dmitry has by far the best track record of fixing any
outstanding issues

I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
said it had leaks ... what am I supposed to think about that ? If someone
does a patch for /Zend and it leaks or is suboptimal in any way, it does
not land on Dmitry's say so, but it's okay for him to merge stuff with
known defects ... I think the problem there is quite clear.

> Functionality isn't everything.  Very few extensions have a technical
requirement to be bundled - it's much more of a question of promotion.

So you want to say that for FFI to be used, it had to be included in
php-src ? That's nonsense, the kind of people who are capable of using FFI
are also capable of installing an extension. From my perspective it had no
justification for being merged at all, but there were very good reasons to
keep it out of php-src not least the slim majority on which it was merged.

> I actually agree with you that the fact it didn't clear a 2/3 vote, and
with a hefty margin - is not very ideal.

So it sounds like we agree here, it was pushed into php-src on an
unacceptable margin.

> I categorically disagree that it is an incomplete feature;  I presume
you're saying this because it currently supports Linux x86/x64?

This sounds disingenuous to me, you are trying to make it sound ready
before it actually is.

>  It's not unusual for complicated pieces of software to first be
available for specific subsets of platforms, and than gradually be ported
to others

That's true, but Windows is a core platform for PHP, if you haven't got
Windows, you got nothing. I wouldn't make such a fuss about windows or
fancy architectures, if I thought there was anyone around who could
actually implement them, as far as I know there isn't and if they are
unimportant to dmitry and yourself, then it won't get done.

> I think there were questionable decisions that happened long before
FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
for them specifically.

Check the date on the rfc, nothing is happening suddenly.

>  I'm not fine with rushing to hastily change the rules (while breaking
the existing ones) to counter a specific RFC.

As I have already explained, I'm prompted to act because of a pattern of
behaviour and decisions that I find questionable, and so do others ... and
by your own admission, so do you ...

I should make clear that I think FFI is really cool although I haven't
found time to play with it yet, and clearly I want us to have a JIT, and
marvel at the achievement. I can't wait to start reading it (again) and
trying to understand. This is not about one or two RFCs, but making simple
changes to give us more confidence in the decisions we are all making, and
it certainly isn't an attack on you or Dmitry, nothing of the sort ...

I think we don't really have anything to argue about, and to reiterate, I
will be taking this RFC to vote.

Cheers
Joe


On Thu, 31 Jan 2019 at 16:13, Zeev Suraski  wrote:

>
>
> 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
>> latter.
>>
>
> I fail to see how in the way it was written it could not be taken as a
> personal attack, but since you wrote it, I'll happily take your
> interpretation of it.  No hard feelings.
>
>
>> You pushed FFI into php-src on a simple majority
>
>
> I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
> but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
> same person, nor do we have a hive mind...
>
>
>> was
>> incomplete (with leaks),
>
>
> I would say that Dmitry has by far the best track record of fixing any
> outstanding issues - not only with his code, but with the code of mostly
> everyone else contributing to PHP, so if there's one contributor where this
> isn't something to worry about - that's him.
>
>
>> and had zero justification for being included in
>> php-src - it didn't require any internal API's and can function just fine
>> as a PECL extension
>
>
> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
>
>
>> still you pushed through with t

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Hi Zeev, Dmitry,

It is not my only concern, I'm grateful for the clarification whatever.

These are your actual words from the RFC:

> This works, but this functionality is not supported on all libffi
platforms, it is not efficient and leaks resources by the end of request.
It's recommended to minimize the usage of PHP callbacks.

To me, a foreign function interface where one side of the interface sounds
broken and inefficient, according to the author, is scary. I've never
worked with libffi, so don't know if that's normal ... but I think you can
understand my thoughts here.

Aside from whatever technical issues I may have misinterpreted or
misidentified, these are not my main objections to it being merged.

Cheers
Joe

On Thu, 31 Jan 2019 at 17:20, Zeev Suraski  wrote:

>
>
> 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 function or another structure. In this case
>> programmer have to care about freeing the pointer themselves (like in C).
>>
>> This obviously doesn't count as 'leaks'.  If it did, we could say that
> the Zend Extension API leaks, as it's completely up to the developer to
> handle memory management.
>
> Joe - if that's your concern, I think it's fair to say it's invalid and
> you have nothing to worry about.
>
> Zeev
>

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Hi all,

I have considered maps ... since it is possible to do in userland, I don't
consider it super urgent, and even if you do, it doesn't become urgent
until PHP 7.4 is much closer to release.

So, we have almost a year; If this flies in, it's *highly* likely I'll
follow it up ... but don't really want to spend any more time on it until I
know it's worthwhile.

Cheers
Joe


On Mon, 4 Feb 2019 at 14:30, Michael Wallner  wrote:

> On 03/02/2019 22:49, Christoph M. Becker wrote:
>
> >
> > Not sure about removal from the PHP manual.  This may never have
> > happened before (except for PECL/idn which conflicted with ext/intl).
> > Might be better to discuss this on the doc mailing list.
> >
> > F'up2 
> >
>
> Oh, it happened. I deleted http-v1 docs a few years ago.
>
> --
> Regards,
> Mike
>
>

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

[Joe Watkins]

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
> > ext/interbase" is open[1]. There is only one voting choice, which
> > decides if the extension should be moved to PECL.
> >
> > Since this started a day later than anticipated, then the voting will
> > naturally run for one extra day and therefore officially close on
> > tuesday, 23th of April, 2019 around noon EET.
>
> Apologies for the wrong link, the correct one is:
> https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase#voting
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Wiki display problem

[Joe Watkins]

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

Cheers
Joe

[PHP-DEV] Azure DevOps Organization

[Joe Watkins]

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 organization on devops, and it says the organization
"php" already exists. Does anyone know who is the administrator of that
organization, or even if we really did create it ?

I have a feeling someone might have just used the name, since as far as I
know, we've not used azure for anything before now. If that's the case, and
we can't find out who owns the organization, does anyone object to using
"php-src" as the organization name?

Cheers
Joe

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

[Joe Watkins]

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 to run CI for NEWS changes, and we can definitely be sure
> it doesn't effect the build.
>
> The same goes for other files like UPGRADING, UPGRADING.INTERNALS ...
>
> Under normal circumstances these files are not changed by themslves, but
> occasionally, we have to correct one of these files and omitting [ci ski]
> puts the build behind by up to an hour ...
>
> Cheers
> Joe
>
> On Fri, 7 Jun 2019 at 13:02, Marco Pivetta  wrote:
>
>> Please avoid doing that:
>>
>>  1. Commit messages are for humans
>>  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 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
>> >
>>
>

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

[Joe Watkins]

Hi Peter,

I think it's pretty well known about, but don't think we have it written
down anywhere. I could make a note of it somewhere.

I think in the case of azure it can be configured but I'm not sure about
the others. I'll try to find out.

Cheers
Joe

On Fri, 7 Jun 2019 at 16:00, Peter 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  wrote:
>>
>> > Hi Marco,
>> >
>> > It wasn't a topic for discussion, it was a request to committers in
>> > php-src.
>> >
>> > We do not need to run CI for NEWS changes, and we can definitely be sure
>> > it doesn't effect the build.
>> >
>> > The same goes for other files like UPGRADING, UPGRADING.INTERNALS ...
>> >
>> > Under normal circumstances these files are not changed by themslves, but
>> > occasionally, we have to correct one of these files and omitting [ci
>> ski]
>> > puts the build behind by up to an hour ...
>> >
>> > Cheers
>> > Joe
>> >
>> > On Fri, 7 Jun 2019 at 13:02, Marco Pivetta  wrote:
>> >
>> >> Please avoid doing that:
>> >>
>> >>  1. Commit messages are for humans
>> >>  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 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.
>>
>
> Is this documented somewhere? I'm not seeing it in the docs held in
> php-src, nor a search of the wiki, for example.
> Also, is this not something that the CI application(s) can be configured
> to do for us?
>
>
>> >> >
>> >> > Cheers
>> >> > Joe
>> >> >
>> >>
>> >
>>
>

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

[Joe Watkins]

Hi Marco,

It wasn't a topic for discussion, it was a request to committers in php-src.

We do not need to run CI for NEWS changes, and we can definitely be sure it
doesn't effect the build.

The same goes for other files like UPGRADING, UPGRADING.INTERNALS ...

Under normal circumstances these files are not changed by themslves, but
occasionally, we have to correct one of these files and omitting [ci ski]
puts the build behind by up to an hour ...

Cheers
Joe

On Fri, 7 Jun 2019 at 13:02, Marco Pivetta  wrote:

> Please avoid doing that:
>
>  1. Commit messages are for humans
>  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 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] Using [ci skip]

[Joe Watkins]

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] CI with Azure Pipelines

[Joe Watkins]

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 are
now exhausted by the thought of that, so that's for later ...

We do not plan to drop Travis, as it will return results faster than Azure
because it runs less configurations.

To potential mergers of pull requests, and release managers - try to make
sure the build is green on Azure and Travis before merging a pull or
tagging a release. While Travis will provide fast feedback for failure, we
should wait for success across the board before taking any actions. Success
shouldn't be more than a half hour or so away most of the time, and almost
anything can wait a half hour.

Caveats apply - test failures may be unrelated to pull requests as they are
now. Azure provides a very nice interface for test analytics.

Thanks to Nikita for helping with this all day.

Cheers
Joe

[PHP-DEV] PHP 7.1.30 Released

[Joe Watkins]

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 site.

The list of changes is recorded in the ChangeLog.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:

Many thanks to all the contributors and supporters.

Joe

Follows is verification information:
php-7.1.30.tar.bz2
SHA256 hash:
664850774fca19d2710b9aa35e9ae91214babbde9cd8d27fd3479cc97171ecb3
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlzs5s4ACgkQ+boK2jHL
2J61hQgAmKPb1F/629KRPXLXoJSnZ+FQ36fkcEU6ZoDMuP+Su7P8TggG+7q/ukvH
pTcGW4dXFxW6Exvr5S9WaigyrVXI3CXvJ5izG0wOSwK+S7CGzOJqDQzCnJJRQtkN
BmxfBi91b7fsoK7rsHi4uJU2Rlr86pcSNRruDSrcRUD+ohmh7xZ4nDScn4ynVnZY
VtR2eeS5mlRp6vW0vJ0OMzGOuXPfxGantiK1mCi15wQCUaW5B+mZaKBb/hhTZiAD
U+xLVoz/sc5rzyaR+7j0GkOd7yyVMXuoWT3//5XPVjOKcPXEukaTSGav739O2ozx
VSPWS4HdjNMN16c3kOkzHD7H4WvVaA==
=1Xj9
-END PGP SIGNATURE-


php-7.1.30.tar.gz
SHA256 hash:
a604edf85d5dfc28e6ff3016dad3954c50b93db69afc42295178b4fdf42e026c
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlzs5s4ACgkQ+boK2jHL
2J4ktAgAm+TgFKUdDeCOVgmQciD+IdcJJR6X1DtFwRWXb0euwy3Z1vUzbINC6hRF
ordoMDw/6axD8Va0a44upT2PBf+RZUiPrxWGRVhRKvj8tPgZPj41FTb5z8zRlZfX
x86KSm6wLWlGCnA+hBcsjjvCozPXJUQDBmIEkxWtq0raDWj0a+sfSAxjMnr+SnWw
jKsduFNteJmwh0VWk3sFEeHYBsBoFE38kt8+mT9h/idwQHCA/hO26qYqan/ZHfKL
GrC+/gExM5zrdVIowzxFzTNrODQct8KxULAqEl+onjduzxY9vXox6QjN3bCms01o
BWyrhAkLWKreWefr9wb/nq3dcEK4Jg==
=DPYI
-END PGP SIGNATURE-


php-7.1.30.tar.xz
SHA256 hash:
6310599811536dbe87e4bcf212bf93196bdfaff519d0c821e4c0068efd096a7c
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEUomVv+37pxkdRoOe+boK2jHL2J4FAlzs5s8ACgkQ+boK2jHL
2J41TQf/fAl6gDhbPTzf1968u8ARTK8cmYCMuWR8m6Z3xlrqGO6KLPJhHGCeJjvT
Hc68zXbbhuZzD3aMSOnt8TuJceQybYuZK04fQqg3TIQvvwIKGFrbFLDSPTXelyfI
rcm2b+54GuGCytboVCjyxhyD0U0mO0ZDn1VrXqU+wEClgEVpNjWfurVmEFWxBhWf
3/dccpPrPEWxgHalGFUdl5WcvHbQK7JORupe/FxfGLKvrWzh096UbqUHgdI+Ytka
5YQXsH6krY2+NFSZeSySXKaHcBr3YLMXLkW0AZJbmKmok60x+4eH2vSzwuGJw+qS
PD6MUH7oc+9geXciNE8tFSTZRhnpHg==
=kEpu
-END PGP SIGNATURE-

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

[Joe Watkins]

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, Christoph M. Becker  wrote:

> Hi all,
>
> I propose to unbundle ext/recode for PHP 7.4:
>
>   
>
> I actually don't mind whether we deprecate the extension as well, or not.
>
> Any feedback appreciated.
>
> Thanks,
> Christoph
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

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, 2019*, 24:00 UTC. This means that
> there are *5* weeks left to get all your RFCs voted on, and your
> patches *merged*. After Feature Freeze, no more changes to APIs,
> ABIs, and internal structures are permitted, unless agreed upon by
> internals, and OK'ed with the Release Managers. Anything after that
> needs to wait until the next version (7.5 or 8.0).
>
> enjoy the weekend!
>
> cheers,
> Derick
>
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

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 process, as nobody can merge an
implementation of this without consensus.

Cheers
Joe

On Mon, 17 Jun 2019 at 20:31, Erik Lundin  wrote:

> Encrypting logs could potentially impact performance alot. My opinion is
> that core dumps and full stack traces should be disabled by default and
> activated only when needed to minimize the risk of data leaks. However,
> logging is needed. You need to get information about what went wrong.
>
> Maybe this should be enabled in steps?
>
> No stack trace (Default?)
> Stack trace with obfuscated argument-data
> Full stack trace
> /Erik Lundin
>
>
> > 17 juni 2019 kl. 19:45 skrev Mark Randall :
> >
> >> On 17/06/2019 18:10, Erik Lundin wrote:
> >> Background:
> >> The latest version of PHP seems to handle fatal errors as exceptions
> which results in stack traces being logged. Stack traces can potentially
> contain sensitive information and should not be logged in a production
> environment.
> >
> > Having access to the full stack trace is, in my opinion, an essential
> tool for debugging.
> >
> > Standard PHP Error reporting should always be disabled on production.
> >
> > On the other hand, security in layers, and the less information you
> hold, the less probability there is of it getting out, or being
> catastrophic when you do, so having the option to turn it off wouldn't hurt.
> >
> > As it happens I was dealing with some issues last month where my first
> order exception handler was failing, and logs were being put into
> stackdriver where they could potentially have been accessed by those who
> don't have direct access to the processes but do have access to logging.
> >
> > I was wondering at the time if it would be possible to supply a public
> key via the PHP.ini and have the outputs encrypted before being written -
> as this is how I handle the stack traces in my userland exception logging
> database and IMHO would provide best-of-both-worlds.
> >
> > The benefits of public key vs a symmetric key are that the logs remain
> secure even with read access to php.ini.
> >
> > --
> > Mark Randall
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

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

[Joe Watkins]

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
>
> https://wiki.php.net/rfc/base_convert_improvements
>
> Two votes, one to raise a deprecated error in PHP7.4 (raised to
> exception in PHP 8) when base_convert encounters something it doesnt
> know how to convert.
>
> Second vote is to allow negative numbers, eg base_convert('-FF', 16,
> 10) would return -255 (this returns 255 currently)
>
> Voting ends 3rd July
>
> Thanks
>
> Scott
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Joe Watkins]

There should probably be a PR targeting 7.4 with the implementation of
"Error on ignored characters" as proposed for 7.4, and a PR targeting
master implementing "Error on ignored characters" with exception change and
implementing "Allow negative arguments".

None of these PR's should cause tests to fail, and where new untested
behaviour is introduced the PR should include tests for that.

Cheers
Joe



On Wed, 19 Jun 2019 at 09:43, Scott Dutton  wrote:

> Hi Joe,
>
> I will take a look at conflicts. The failures are extreme value checks
> which are a result of allowing the negative numbers. If the negative
> numbers one passes I will fix all tests and add some more for the
> negative values. The tests fail because of the unsigned -> signed change
> (but as you say there were quite a lot of tests).
>
> Would it be 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.
> >
> > 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
> >>
> >> https://wiki.php.net/rfc/base_convert_improvements [1]
> >>
> >> Two votes, one to raise a deprecated error in PHP7.4 (raised to
> >> exception in PHP 8) when base_convert encounters something it doesnt
> >> know how to convert.
> >>
> >> Second vote is to allow negative numbers, eg base_convert('-FF', 16,
> >> 10) would return -255 (this returns 255 currently)
> >>
> >> Voting ends 3rd July
> >>
> >> Thanks
> >>
> >> Scott
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php [2]
> >
> >
> > Links:
> > --
> > [1] https://wiki.php.net/rfc/base_convert_improvements
> > [2] http://www.php.net/unsub.php
>

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

[Joe Watkins]

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 7.4 with the implementation of
> "Error on ignored characters" as proposed for 7.4, and a PR targeting
> master implementing "Error on ignored characters" with exception change and
> implementing "Allow negative arguments".
>
> None of these PR's should cause tests to fail, and where new untested
> behaviour is introduced the PR should include tests for that.
>
> Cheers
> Joe
>
>
>
> On Wed, 19 Jun 2019 at 09:43, Scott Dutton  wrote:
>
>> Hi Joe,
>>
>> I will take a look at conflicts. The failures are extreme value checks
>> which are a result of allowing the negative numbers. If the negative
>> numbers one passes I will fix all tests and add some more for the
>> negative values. The tests fail because of the unsigned -> signed change
>> (but as you say there were quite a lot of tests).
>>
>> Would it be 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.
>> >
>> > 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
>> >>
>> >> https://wiki.php.net/rfc/base_convert_improvements [1]
>> >>
>> >> Two votes, one to raise a deprecated error in PHP7.4 (raised to
>> >> exception in PHP 8) when base_convert encounters something it doesnt
>> >> know how to convert.
>> >>
>> >> Second vote is to allow negative numbers, eg base_convert('-FF', 16,
>> >> 10) would return -255 (this returns 255 currently)
>> >>
>> >> Voting ends 3rd July
>> >>
>> >> Thanks
>> >>
>> >> Scott
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php [2]
>> >
>> >
>> > Links:
>> > --
>> > [1] https://wiki.php.net/rfc/base_convert_improvements
>> > [2] http://www.php.net/unsub.php
>>
>

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

[Joe Watkins]

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?

Without an implementation I can't really consider the ideas proposed,
because they are just ideas without proof that they are reasonably
implementable.

While you can technically move forward with an RFC without implementation,
in this case the implementation should inform our decision at vote time.

Cheers
Joe


On Tue, 25 Jun 2019, 23:19 Benjamin Morel,  wrote:

> Impressive work indeed, this would be a perfect addition to strict_types
> that would remove a lot of WTFs while preserving BC with older code.
>
> Please note that the formatting of the RFC is broken after the Bitwise
> Operators section.
>
> Ben
>

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

[Joe Watkins]

For reference, and because it may be easier to debug than xdebug:

https://github.com/nbs-system/snuffleupagus/issues/293

Cheers
Joe

On Thu, 13 Jun 2019 at 20:50, Dmitry Stogov  wrote:

> I'll try to check what was wrong with this commit and xdebug.
>
>
> Thanks. 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 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 form, I'm sorry, I just pushed in the wrong shell.
>
> If the revert is terrible, feel free to shout at me and revert the revert.
>
> Cheers
> Joe
>
> On Wed, 12 Jun 2019 at 20:04, Derick Rethans  wrote:
>
> Hi Dmitry,
>
> I've just fetch the latest PHP-7.4 source from GIT to finalise Xdebug
> support for it, and after compiling PHP and Xdebug, I now run into the
> following error:
>
> Warning: define() expects at least 2 parameters, 1 given in
> /home/derick/dev/php/derickr-xdebug/run-xdebug-tests.php on line 2749
>
> Line 2749 is not using define, and instead is:
> $JUNIT = getenv('TEST_PHP_JUNIT');
>
> I have tracked this down with git bisect to be this commit:
> https://github.com/php/php-src/commit/374f76998
>
> Could you have a look and let me know what's up? Joe suggests that this
> might need reverting.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
>

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

[Joe Watkins]

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 form, I'm sorry, I just pushed in the wrong shell.

If the revert is terrible, feel free to shout at me and revert the revert.

Cheers
Joe

On Wed, 12 Jun 2019 at 20:04, Derick Rethans  wrote:

> Hi Dmitry,
>
> I've just fetch the latest PHP-7.4 source from GIT to finalise Xdebug
> support for it, and after compiling PHP and Xdebug, I now run into the
> following error:
>
> Warning: define() expects at least 2 parameters, 1 given in
> /home/derick/dev/php/derickr-xdebug/run-xdebug-tests.php on line 2749
>
> Line 2749 is not using define, and instead is:
> $JUNIT = getenv('TEST_PHP_JUNIT');
>
> I have tracked this down with git bisect to be this commit:
> https://github.com/php/php-src/commit/374f76998
>
> Could you have a look and let me know what's up? Joe suggests that this
> might need reverting.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>

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

[Joe Watkins]

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, something is considered a primary vote if it could be conducted
independently of other primary votes in the same RFC - ie, it is not an
implementation detail.

So, what we have here is multiple primary votes ...

[1] https://wiki.php.net/rfc/voting

Cheers
Joe



On Sat, 22 Jun 2019 at 09:23, Kalle Sommer Nielsen  wrote:

> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalys...@gmail.com>:
> > My first question for many of those is - why? I.e. it deprecates a bunch
> > of niche functions. Most people do not use these functions, so they
> > probably don't care. Those they do use them would find their code broken
> > or produce new warnings and needs to be changed. I have hard time
> > identifying whose life would be made better by these changes.
> >
> > Now, if some of these functions are hopelessly broken or have no valid
> > use cases - like magic quotes - then phasing them out makes sense, and
> > the audience whose life can be made better are people who use those
> > unaware of them being broken, or plan to use them and would thus have
> > broken code unless we warn them (or remove the functions, eventually).
> >
> > But for functions that work just fine, I see absolutely no reason to
> > introduce friction without any apparent upside.
>
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
>
> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
>
> hebrev(), hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support  lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
>
> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
>
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
>
> > For the specifics, I think things like removing allow_url_include
> > requires separate RFC. It's a serious functionality change, and bundling
> > it with 20 or so other changes would not allow to properly consider it.
> > In general mass-change RFCs usually are not very conductive to properly
> > discussing each specific change, but mixing changes of different types
> > makes it even worse.
>
> I will have a chat with Nikita regarding this.
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] MODERATE spam

[Joe Watkins]

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?

[Joe Watkins]

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,
>
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
> 2. Many people think it is a security feature and use it as such. However,
> open_basedir is in reality a "best effort" mechanism, with known
> workarounds and more regularly being found. Especially when it comes to
> interactions with 3rd party libraries, enforcing open_basedir is simply
> impossible.
>
> What open_basedir tries to do must be implemented on the operating system
> level to work reliably (and of course such mechanisms exist, such as jails,
> chroot and friends).
>
> I wonder if it is feasible to drop this ini setting? Enforcing this doesn't
> really seem like any of PHP's business. If not, I think we need to at least
>
> a) make it clear in the documentation that this is *not* a security option
> and only exists to prevent "accidents" and
> b) update the security policy (https://wiki.php.net/security) to state
> that
> open_basedir bypasses are not security issues. I believe this has been part
> of Debian's security policy for some time already.
>
> Regards,
> Nikita
>

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

[Joe Watkins]

Morning internals,

The abolish short votes RFC has been accepted and the Voting document
updated.

Cheers
Joe

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

[Joe Watkins]

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
> > been done.
> > So I would like to raise the issue again, there are a various of old and
> > empty branches currently in git, would it be possible to remove them?
> >
> > 1/ Which ones *specifically*?  Some release branches are empty only
> because they didn't need to be patched after release (and our release
> process was different).  Some are old and even "abandoned", like the
> first-unicode-implementation, but they serve a useful historical purpose.
>
> 2/ Why?  Git branches are lightweight and don't really impact the project
> in any way beyond enumerations.  I'm not against getting rid of truly
> pointless branches, but I'm also not sure what the appeal is.
>
> -Sara
>

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

[Joe Watkins]

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 necessarily not need be removed, if this might be a better
> > idea, why shouldn't there be a php-archive or something like that as a
> git
> > account or repository where all those historical branches may be kept for
> > historical access?
> >
> > I think removing isn't making sense to me as well, but archiving them
> > should be without not much justification like currently requested.
> >
> >
>