[PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Rowan Tommins 

On 01/10/2020 15:23, 肖 鑫鑫 wrote:
1. Opcode binaries can be published when binding to a PHP interpreter 
(version dependent) release product, rather than just the PHP source 
code(for example, JAVA and .NET is version-dependent)



Just to clarify the comparison with other languages:

- Both the .Net CLR and the JVM are designed to be backwards compatible, 
so that an assembly / class compiled for version 1 should run without 
re-compilation on version 2 (but not the other way around)
- Until recently, the .Net CLR was a very stable target, which had gone 
through only 4 versions in nearly 20 years (confusingly numbered 1.0, 
1.1, 2.0, and 4.0)
- The JVM is specified independently of the Java language, and has 
multiple interoperable implementations


This is very different from PHP OpCodes, which are not documented 
outside the engine's source, and have no provision for backwards 
compatibility. Not only are they likely to change between annual 
releases (e.g. 7.3 to 7.4) but a change in 7.4.23 could conceivably 
change the VM in such a way that code compiled on 7.4.22 would no longer 
run correctly.



The Python .pyc (and .pyo, which is just a .pyc created with 
optimisation turned on) is a better comparison - like PHP, it is an 
implementation-dependent bytecode, although it appears there is some 
guarantee of stability between bugfix releases. Its primary use seems to 
be accelerating runtime on a single machine, not distributing a binary 
elsewhere, and OpCache already provides that for PHP.



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread 肖 鑫鑫 

hi

This patch addresses the following issues:
1. Opcode binaries can be published when binding to a PHP interpreter (version 
dependent) release product, rather than just the PHP source code(for example, 
JAVA and .NET is version-dependent)

2. Extend compilation only online to compile anywhere. You can avoid problems 
caused by cold starts by publishing more code

Explanation of some questions:
This patch simply changes OpCache's process of detecting the opcode cache 
against the requested file, allowing it to treat the current file as an Opcode 
file. .
This means that files compiled using the opcache_complie_file function are 
still cache files that can be moved anywhere, so it is up to the developer to 
ensure that the compilation is consistent with the version of the interpreter 
that is running.
When a developer compiles with the opcache_complie_file function and enables 
the relevant configuration in the running container, they should be aware of 
these limitations and some of the functionality failures.
I will add PHP version information when writing labels, and give a hint when 
the runtime does not match the current version.

In addition, the Phar file does not skip the compilation of Opcache, so it also 
supports packaging opcode files into the Phar file



发件人: Nikita Popov 
发送时间: 2020年10月1日 20:30
收件人: Rowan Tommins 
抄送: PHP internals 
主题: Re: [PHP-DEV] RFC: execution opcode file without php source code file

On Thu, Oct 1, 2020 at 1:44 PM Rowan Tommins 
wrote:

> Hi,
>
> On 1 October 2020 10:36:20 BST, "肖 鑫鑫"  wrote:
> >I commit a new request path, the request is about execution opcode file
> >without php source code file
> >this RFC provides similar to class file of java and pyo file of python.
> >patch is: https://github.com/php/php-src/pull/6146
>
> I'm sure someone who knows the internals better can clarify, but my
> understanding is that PHP OpCodes don't currently have any stability
> guarantee, so you can't rely on a binary taken from one version will run on
> another, even within a release.
>
> In order to be useful, this will therefore need two things:
>
> - a header in the file identifying the engine version it was compiled for,
> with an error raised on any mismatch
> - a policy of how to manage that version number, and how users can know
> which versions their binary files will work on
>
> There's probably a limit to how stable we can (or want to) make the VM, so
> these files will never be as portable as a Java class file or .Net assembly.
>

This is correct. PHP uses the "system ID" to determine whether it is
possible to reuse compiled opcodes. This system ID is used by the existing
file cache.

The linked pull request however explicitly disables this check, which is
not safe. And with that check enabled, this feature would probably have
limited usefulness, as the cached file would be bound to a specific PHP
patch release (and to some degree to which extensions are loaded).

It would be good to know what the actual use-case for this is. If the goal
here is to distribute pre-compiled PHP code without the source code, then
this is not going to work without making the opcode format stable (which, I
think, is pretty unlikely.) If the goal is improving cold startup
performance, then I wonder what the benefit over the existing file cache is.

Regards,
Nikita

[PHP-DEV] PHP 8.0.0 Release Candidate 1 available for testing

2020-10-01 Thread Gabriel Caruso 
PHP 8.0.0 RC 1 has just been released and can be downloaded from
https://downloads.php.net/~carusogabriel

Or use the git tag: `php-8.0.0rc1`.

Windows binaries are available at https://windows.php.net/qa

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net

8.0.0 Release Candidate 2 should be expected in 2 weeks, i.e. on Oct 15,
2020.

Hash values and PGP signatures can be found below or at
https://gist.github.com/carusogabriel/cb6e1b957fff40fc1bc9425a01cf6e89

Thank you, and happy testing!

Regards,
Sara Golemon & Gabriel Caruso


```
php-8.0.0rc1.tar.gz
SHA256 hash:
19f859109540f6bc7f5bf4de71c1f363cd4f171a7c1f0e5f4f0abe5d40f271de
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl9zuK0WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj0aQD/9TdKfgGCgaQ+A5ql94YA3/+8rM
+ff9pbHfJW9hi7MCimLZSQreDV/6PmR1IMedX1VDw7XI6cySYD1Khm0VBfUfDbzO
RbOB7pH9VeCopQeEW4ugRGzgHft/DfnWFv12KGPKx5BA6jkd9y8QfxXxXVTfx4pt
aGvoSZi8wGKlA2Nb85wVo4o0T0/TGa/4tHQ9lXp4/tZE08yivepF9K1BxzMJcU+o
/37P6GAXfIVRRqRfTIMiTxkEax8sslgTdaHPJjk8BAzEik9l3aY62Op8YfAolFMB
50SmwHBRc9ZIdboXlrU4Fmce41bH9KnN/TE6Y5xDaVgXosFhsdfWz17SBoVbKQAu
mrR803Vu2rv9w9x18gViGJk4yt0bXbbvludQ8zP7CfyP8HV8+9yFI8A9b4wbFDWk
f8iCGDcLKZgkYCbxcnr3yKAJHv4TeiRzE1JjrH5BrzZX4VC2v8wEsA71uX7pacpd
aJTKl/91/b4y3dAj5d45lmdbMA66oJ8QHG2Tp8cAipHvoH7IBxsgUAHh/X/bqzBI
XbNCzI7x+ti8LrvOfNA7bmROE4IPZOeE27w7h6OktsjIpL6iOwynrJ8egJny0Zm9
0e437vdM4dV3U1fJlWAQM8QiY21sx/WPhHOBP+51Ca9dU2aeVP2M9xTItlhSh48t
wG41Z2YhI4St3McbAQ==
=ooCS
-END PGP SIGNATURE-

php-8.0.0rc1.tar.bz2
SHA256 hash:
87e0afa3e6a33a2c16f5a0db6978a5a31745629501d7590d2d2f3bbac4dc4934
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl9zuK0WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj1SwEAC6hilc7GvBmfS3tabHMEV4VfPs
JoY4UpGxsZMVK7R9TAeahM21CFgeTEGp5q0iqSi6oPxofjueWU4ZOY5fGYPmEpc9
1qmU0cS2cukPQxANA1oW0fHoMk1B6hWpQQmGriYzTyu40if3uhyYgcdF6JuYJFvk
d0MKc7fNnyVKIn8IMmHi7+4EPyHTAOIcY+Es6j+o3MfFp+OyZXP9IIj1QggXQsTr
rEXJ6PBlRxq3dHl9yW8F/cuttyXtNfTPl+gXD9TuLzcSjFK79I0sKWKjKgN8RtWA
Z7sYzFEvwyJhqluroAm0FHur/1JsvHO0eHCrW5WEVRsYoLFfUXp/WIilnd0wG6ch
UJLnf6xmyr2Q45CkLixyAgDQ3m8DQ2ISGhKApVaQogwN3oag1yHqFESF89C6c2+d
9Q42kRcV+yQaH+n7Jj7V9L+4/Dc4YLpjXB4csyntCIU11N2O4gr9FjFAbwrB1ozx
s/EA+uhbW683UaSc86pF6syjqSzx0ySPKuTzmOPj+gmhmJ0qHunliajRiGoePuCP
/d9usN2egu8BNQNmnY4YXFfHq5AU8kob+Zn/y6qMRdTavjvLhnF6OLHHz1G9zDlC
0uSgkYqx5Ws54yPw+gRCx7RK9gYK/oQFmJaTxLm3msLF3vDrN8pZ+CmgOJSWB0M5
ZT9mEzQX08GaMyuu/g==
=hkrj
-END PGP SIGNATURE-

php-8.0.0rc1.tar.xz
SHA256 hash:
350a80e26561ec5b926e84d4f6cbbd76d54d7cb77444fd1b1a16310201fc0f7b
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAl9zuK0WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj8ROEACeI/lCVGk2pSDFlAkcNo+AGvXR
x0+Xxs4gRsrSRQH/jrUK2rVt5ZBKwwy1oSYQk2m/7CfR1RUJ+GkfDHRVcqCN+vZ4
0DWLDS4mT85SiXP1uUrWhe5H5YMehSG4HWrncG3V9vEMJLq4v87QbGih7MU4S9bO
eXP85qTnq2IvmAGA2cN9gLUsC6trNisUMj8QRwYRxFhcl/SDAtwE1k2F1XGAAhgD
TaKK/NC7rfEOIwbpN06DiejgalLI+NR8pSoemC6hPB3+ZQ60qwBrFknDHIFXrBtV
/L9sS4hDRMyC0GMLMhWri81JQXpNsTYJkxfTfHT+LMwINKjfjuIuYNZPtxXQVIKR
DVCvOuLqbyggrg8hUDerzfkqEqRsi15W62OgDgDw2Jwx8P7+jKl62qcR4CTqXQ34
ShMTnc57nvu+Hgf+xKIXNHfQ7VsJUN8wfIkS3h797EIomrcMUL8yEeIDqPiqdeRL
4w/iQV3zsdetVcNXitwphsFxvrf9g12C1pzIQmesPb8ZR+m18tLaBfOSQP4wQe8H
dXsKZO3cOzFrxzikzbDtAV2WTfOrBzgP16kVeSxA5QLl9A7EtDcyObx4jbesTKOB
Qk4cvBsseVNTzwAhwYhIXwhRZYnY6aXYnz4qqNqWcku6H3LT2S9P3kuptdLck8MZ
3TpO6pD5K+/UYGEKBw==
=hGkQ
-END PGP SIGNATURE-
```

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Levi Morrison via internals 
On Thu, Oct 1, 2020 at 9:14 AM Dik Takken  wrote:
>
> On 01-10-2020 14:30, Nikita Popov wrote:
> > It would be good to know what the actual use-case for this is. If the goal
> > here is to distribute pre-compiled PHP code without the source code, then
> > this is not going to work without making the opcode format stable (which, I
> > think, is pretty unlikely.) If the goal is improving cold startup
> > performance, then I wonder what the benefit over the existing file cache is.
>
> The only use case I see is to package commercial closed source
> applications as Docker containers. That allows the packager to ship the
> compiled code along with the exact PHP version and configuration that
> can run it reliably.
>
> Regards,
> Dik Takken

Note that for PHP 8.0 we made the system ID change even more than it
used to because doing so fixes sigsegvs when switching what extensions
are loaded (common when trialing an APM product, or loading and
unloading xdebug) when file cache is used. This means that it is even
more important to have sources than in the past, and necessarily so
because of real segmentation faults.

So I second Nikita's opinion: this is not going to work well without
stabilizing the opcode format. This may be possible, but it would be a
lot of work; it's not happening soon. If you do it anyway be prepared
for plenty of crash complaints.

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

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Dik Takken 
On 01-10-2020 14:30, Nikita Popov wrote:
> It would be good to know what the actual use-case for this is. If the goal
> here is to distribute pre-compiled PHP code without the source code, then
> this is not going to work without making the opcode format stable (which, I
> think, is pretty unlikely.) If the goal is improving cold startup
> performance, then I wonder what the benefit over the existing file cache is.

The only use case I see is to package commercial closed source
applications as Docker containers. That allows the packager to ship the
compiled code along with the exact PHP version and configuration that
can run it reliably.

Regards,
Dik Takken

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

Re: [PHP-DEV] CallbackFilterIterator is leaking memory

2020-10-01 Thread Nikita Popov 
On Wed, Sep 23, 2020 at 11:29 AM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:

> Hi,
>
> can someone please verify https://bugs.php.net/bug.php?id=80125 and fix
> if possible?
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
> Michael Voříšek
> ČVUT FEL


This issue is fixed with
https://github.com/php/php-src/commit/afab9eb48c883766b7870f76f2e2b0a4bd575786
and
https://github.com/php/php-src/commit/2c1b5c43656336b6a19070a3529c411084f0304f
for PHP 8.0.

Regards,
Nikita

Re: [PHP-DEV] PHP 8.0 branch cut - The Return

2020-10-01 Thread Sara Golemon 
On Tue, Sep 29, 2020 at 5:00 PM Gabriel Caruso 
wrote:
> I'm gonna borrow Nikita's idea, and tag RC1 today without cutting the
PHP-8.0 branch.
>
Late to the conversation, but I stand by Gabriel's call to proceed with
release names as-is, but defer branching till RC2.

To be clear, we're calling the ABI frozen from this release (RC1).  Changes
to the ABI should be duly considered and rejected if not essential.

The user-facing API (of particular concern to named parameters) may be
considered still (partially) fluid up until RC4, but please take every
measure to finalize these changes sooner rather than later.  We want
external testing to be meaningful, and that only happens with a stable API.

At this time, we should consider RC2 as a firm branch cut date. If we still
have a high enough volume of changes going into 8.0 to make merging
problematic, then we have a more fundamental issue with the release and it
will be time to consider delaying GA through the holidays. _Nobody_ wants
that.

Thank you to folks working on the JIT for reaching a stable point for
release, and thank you to the folks working on named parameters for their
continued dedication to getting our public API into a solid state.
And of course, thank you to everyone who's been contributing to PHP for
both this release and the 25 years of our storied history.  I treasure you
all. ❤️

-Sara

[PHP-DEV] PHP 7.4.11 Released!

2020-10-01 Thread Derick Rethans 
The PHP development team announces the immediate availability of PHP
7.4.11. This is a security bug fix release.

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

For source downloads of PHP 7.4.11 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.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.



php-7.4.11RC1.tar.gz
SHA256 hash: 0341b128417cf22acbcc5df9491af43253d28e308577140b5fdde3f54806a817
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl9ge9sACgkQkQ3rRvU+
oxKPjhAAp6qauVYzv39IpLWBfnU7gmy1kFSMDCLAbdiBQxNBL0tjoMMSKZyUAZKv
q8xqyAftG/IkpjbgnYDM3qrY0ycHCKxdVFvliC60Svw9Ax71eeyB13BgpGTbSlN8
Ykvuvcn6laSiD5H9Z2h7Aq2lzHIwpQpYk8hMXkWz6D+QANXOghGCcekmxj6xZNel
0TtCaoRjgz689xXwAEBfxoWGsIycorkGTUqWHjCZk59WXEdbors3Bj3AJFw5l8pT
xq79o1e86nSc5G1VSzqljW6rheo3XQ+t4MrfoVgTp6VfK+fQtGdiogWh/OVYxt6z
00cnsQ5idkouKACIBFDaCEJ1U+OvADhsPm8LwJ/tjteSzJov3JA8PcVxmEgdzCuH
llyN02UWlk/XoBXGtQxJLzKGDy69QYeRn3C/kLLNYVxKnPRDbOnbkI55zXHJjcpy
g84NljZCSgNw1wcr5/SMK8OIMNbeoQCB82pTb2k4L6qt/NR3WIj4zPdBLV/87pkV
iKXdVLi++0dE+7CAPunDLFWd7NGBni0sZjjXMSjpgpqqOwC9yGSWo+WYsKoEThZy
nDo8kcj4HMrRXcLzLWQRZ++XEtkV7YOES3wLmVfb+Cw7JY4q5OROL9EH8NHmv8+d
3YZetWgyOj9y45qjuLyVFAKgZeU187s+hwdt/iEJBHElWq5Z2bk=
=OqAF
-END PGP SIGNATURE-

php-7.4.11RC1.tar.bz2
SHA256 hash: 291401034e42496b9b80ba630120c1782f28c98894050fefcb94b7a910b4d019
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl9ge98ACgkQkQ3rRvU+
oxLsTg//WuYboM2uaK3cUhG9qjdvVKJU1tHBKYONTLB0qV8lE82jU5czYYKHeQO2
unqyz4uVUmncr/vN4RyzVTawyKLjXaTQNAu5pn00az/8GND7uE+Dhqo7dfw+IBrw
WA0+CSCF47/NM3rExU2gNaZJswm7wtraKRkiYl+JGf7qEqSxCXUUZsb42Z+PP37k
Z7iLUxbHJ6Nlisvi6cg0YEm9Rp8uCFrOt0ur4lXSwfDdmSSYVDELe8+dwhq5oB2B
xCrMXrWHJogC36MmwyQrQBwsi2aEGEG/SWjS90fNn3cMKbWxGynF6LeKpTWQ0Jvm
mY+/wCWcV5HMLKS70uIq59tDlI7IJetLxsaW1rCrgnuPSi2doE+r1IoWVnqTeNST
o7o96huvfA5TWa10Q3Gphkz9Y3ZXWYkCkToQO06tTtSbXp9ZHYQICxMUJBdFU8Sr
zqzpqPK5B3E4TgkxTszF8n2ET/3EQIcnqL8hT9zr261YK0ol3/OCWK5qOA0qo9Ch
f4SnHO7hYlCXISmBzWNXgvtj4RsuFrPPHNHALiEYFSQx7smo4Ny0Qdrh2ldSt/Wi
YxBCkab0ruLGc/sNNdDjCX7GhV/WJjOQDRHPnT5MwIsOVpg+04R4cGwy246b08mD
oCMpzvrFsh73SrTsGWb89FMZzEr0ouaQTNBbcHYEXOkFJmwq9Bs=
=HqZY
-END PGP SIGNATURE-

php-7.4.11RC1.tar.xz
SHA256 hash: 127779bd18978a65573befd7166e560cb2b114313b9260d52f0a6dd370f66fb0
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl9ge98ACgkQkQ3rRvU+
oxLjjA//XUteINi7VRQgfHGSAWu4IvOXJkki4ZOJ9hQ+jfincswS+/l5TgFsmIAO
ys/HosiFA9H6BwxdTqnfiA6W0aH0cEhA2jzkNA3r9XSRX996QY34Yf2W4jJhNfMx
xZ/g9S47yLo+S9ZNn8PibKbDD7SDJgJwYiaFktxi7mrOJAuOy6HjKD34NTPvBemh
lEuN2iar8DPnRvGWbfHR3x3MFdeQY0JIFBwE4HifykJM+rG6dd2c4SMHoB/Ruk4/
nHu3e56jFhcObWE2OBk14/NCaw7+uZ7QXo2f9cj1aKwGmFEyd833NoaGQlrV/Ssw
8vAuulJ9P9ffd0eJBolAZLY+jHs8qFn9WsYu5BJ6PZNaU9tiRcR+3X/VmTqX/mQW
lVmacIGibYgYxZUHMD0tz6uocwxKKqMfi8zAnefV7vbIcyJ4oWXQxzf/5DP1pGC3
teBmJD84Uja2d7FbQMb3ODpYkPo/MYVy6stAVLa0rWLJGKw0O454WzfD3E44B3Yl
Hs0B3USEhWUaGhvTCpnoLshRd0zHweqvAeVQE54CgmzV6TGxMlqTH40kIlDj4aAF
tp2A0rZIm7pFtincqh870+sVX08bAJJF35PgjUYq2EzhO51smyDA5PKgXWWlDlPW
zrxmoDpV3z3eH45ThNVl9+jAKnxzibkaHCCqtiGgxiuhzNPN7FA=
=elZr
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

[PHP-DEV] PHP 7.3.23 Released!

2020-10-01 Thread Christoph M. Becker 
The PHP development team announces the immediate availability of PHP
7.3.23.  This is a security release.

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

For source downloads of PHP 7.3.23 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!


Stanislav Malyshev, Christoph M. Becker


php-7.3.23.tar.bz2
SHA256 hash:
fdad4605508042c6964151379475daea36c43e03b11b1e79d4ae6b04c04c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl9y8b8MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2GTAP/Aq9Z+ChPy3opLePbQP0JvR1QBT7Ocgo9ea0CkH2
c3SOXkPz8uYDMPuSL0avf9vA1LEVjTpD4KiTAju/Jo4bW3m7g820OzjRmhoH/rqB
IRD4bixlrf+cQJyg/3Oq8Y7Gvw7F5Kp7IhgHq4UtfT9zrsbJpWyohWymzd7Od/3W
6Ojoaeq/+p62MkA65no2mUic+ELG0Z90lO1eCJVskOATcIKUCCWUPl9aYzI3uwHY
cR3h9oAi2ab/JUxLIt1cW49/hRKWkbs5w2mqRDc+KjGCS/z5HLlTr78wUoUuBSzh
0ejgZQxnRbk93g5/TOg6P4wQIr4RSt3QojkXwHJ8daqeUkFlwq65vVVHQBdxzx45
ySCANnhPAWHEPNVDpGOCzIcmtgGzLk3ILoqJ4NRIlp7cN3qTAdNW276nms/INwIW
QGF+iIfdTRTcUA0fViWMq0b/qxvjJfaHwnhHA0v91+VwZeaLdQmx+fuXxtOe9SrP
5pTDLRrQak4ek5sN8lvai2U6lPHFC2SecIW/CDfvXca5eIpsHAIOUqm1LSabuneg
pzVDf09YrAhqsVAt6JaWHRDS5sNkRHslk2xlc4JqHQGVVDhgPg34BhlaOduhnmw6
LPKk7Nr9RmvK80VnFjSAEaovsAdc8Ws8vqYWXm3lhoT37Bvtfly43VSe9VuD8pNP
t/0u
=j5wS
-END PGP SIGNATURE-


php-7.3.23.tar.gz
SHA256 hash:
a21094b9ba2d8fe7fa5838e6566e30cf4bfaf2c8a6dce90ff707c45d0d8d494d
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl9y8b8MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2N9cP/0DzFyHCtDGYnbXI+VwCXTYnzfoBD1Y1SjvXmAdy
Icgczy9Mdi4w60LVmNRy/dEdQrd0xwCiLWuIs9c5cayg62Yi9EuwVrP5Lqn5dZQW
tZjhC+a2Uan/9VUGpGf/Bhfe9bP5ztt1mInFjtBGiqcKGS9guLIZgPq9QqNGsJxb
CSivYsiFQfVKpuBk73lNJ6nx6XETVp+VtQxd8h6W2eoSlKg2QLIR66VD3dhVTGdR
+dp/8KSK+VKpz6WMZh+3WZv7pr1Gf8oCehDDxc5YeFVgJ/42DG27yZ8NdxJ3CUAe
aEXW8KnwzKrHK4N97thUUe5aKS9MfSD5W8NaP0pCk+21wv743B49hBOtrOP9oLw2
NZX2QfR5OvF06lQt1KCVoPKYvuFSb/iH8xYGC9C6tPhF/IpGzL4i/OscaejkUx/r
tHWwxU4UPwAf5+ijvN8k5djHS5yIe/sFdOAI5sgKKUucaZvkqvT85uafq9VFgHrQ
gCEZlZi+okUmU33CShMm4JACT4BwVha0AVD5SfDpGLLsutTs8PMkwwuel0AxxtNf
ac6OE7Duk2NMcVXPKQdBve5fgZiE3iF3TaRasnN4GaZzF2JolyMNasU31VSDNLpI
jGRty0BvacjpuGMjJP6WEZ28lgTlO3jNonhD8HrBLP6zARiuROiZwrodZujuxJ3m
/J+2
=RfU2
-END PGP SIGNATURE-


php-7.3.23.tar.xz
SHA256 hash:
2bdd36176f318f451fb3942bf1e935aabb3c2786cac41a9080f084ad6390e034
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAl9y8b8MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2ndkP/RZStW3W/qLdvDeoxQR35+446xDp7aI1Q7uPurrn
ZkRhJP6lND11fRj7cCowJ0Mn2GgWB2jXxwKTAtbGhD9mwb2NSwcYTXR1/CatwXCs
vu5jwfez6aBPn6kPtZ2+97eQFNI6nVzEX2+d2CUr8Ep3f/8Mqe75XGhfWlNk87fs
zRxFRPoI/crSk+mrL67zNovtuOEH0BDc0QSgvcPSM2EiT7WsXGaZr2J8/VqRy0EH
yW8pPWHnIwnJCne7snnubrtQWIO+nn3yy7P514Ldd0RWBrRyOLChRoPfvwql+6En
OQ8wLIx0EpfyUUndwDrgKr+MTREBA2ODSl40Z06thIr786CkmXS5LTAVu7G7cJOL
nK0MMwHF3iQjWFtNdee0njd8PmW61zrVngooj2G1PpA6Grq2yqQqCb1VBSph4HN/
NTeSVQ0K7NlW0DXKsdG9FfyJM+N+DzGAlS6cMTOsqMmKHUyMp6b02FEGDUPgj9VW
aFBckO7LFzdAZqnv0rv0jdxKe/qKwuZuxsq0EkOwSxEYdIjuGycSeDOLgnfo8vY/
DPWZkPNe6yfhSusz5QN/1Dj1nyEYVlYvoANPCN5AoPqIwnQ0tMS2VVGspH+J0ZIF
n88XBCK3w0it1MJsGADyetFbDSmaVFG6MOKALJX23d32ASwbMyJA7clOmBhg4V0m
0/wJ
=/dnY
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 7.2.34 Released

2020-10-01 Thread Remi Collet 
Hi,

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

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

For source downloads of PHP 7.2.34 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: https://php.net/releases/7_2_34.php
Downloads:https://www.php.net/downloads
Windows downloads:https://windows.php.net/download#php-7.2
Changelog:https://www.php.net/ChangeLog-7.php#7.2.34


Many thanks to all the contributors and supporters!


Sara Golemon, Remi Collet




php-7.2.34.tar.gz
SHA256 hash:
8b2777c741e83f188d3ca6d8e98ece7264acafee86787298fae57e05d0dddc78
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJfdBT1AAoJENyf+NPuWvJ/40IP/29rWc3h1/MyopXjuUn1w1T8
JVGtQ4cJYujlWDe2/NkNwClEFkTbvQMMdat8+B0GuONvw93+N6EGmkJlmA6KRGiN
wn600x4m45eTwao2MjpQJILgmHgeLAtG9JKCUly8PZCkfetbI1i+r0qrvtB+Z600
nFPX1PUaRdeo9EeM4Jfey2xLwuVgACYpWlY5oWjaQRBkB736tqdh7ZYtyCHh21F6
oEF8kaRdXRynWNKGTSikjFx4eMdj0z9sU7cAkqkLCUg2QJ8xumPpiTrzeph71iJE
eQoVspcCs8AkRECW38YrL9FJD1HBe/0BA5IzLxtnBhq5N01wCGnWMKucRf2KqARw
0LFjqIgT/W6R9+Nq1gw5yrQQAFpntpINwtfmN/89o7LOPGKE1yhJTLS1r2Sn4+dL
ZGeNy3b+BRJdTp26mfNQiEXXuYMsN7q8Z+OocP90lri4gktNuL9maKtew0z8uVYX
7mJSFxhPyn+8UOxtowtljhT14gd4p4/DIuI91IgpX+OxkIN0dcPE7JUIbACNDVTf
liGHtcSCl3+yMlc+Uk1EIkLSCdr/jydi/SAlLNO8miGZj/BEV/cEhwDKAiIeUn+U
AgxqkZQhk8cKhnjmYiYVGIwoOgZ/a6JO9EhsV6jKPB9HOPc5PJ2U0oKjLa8+Pq2R
6EsTFHet/oCL6AA8VvUj
=5qT8
-END PGP SIGNATURE-

php-7.2.34.tar.bz2
SHA256 hash:
0e5816d668a2bb14aca68cef8c430430bd86c3c5233f6c427d1a54aac127abcf
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJfdBT5AAoJENyf+NPuWvJ/lWEP+wa1Pqr0l79zEC6Ca9D9wPtC
TdJFCSNZ+D6htPJ4JekQqdWTh0LG093InylPtnWPY/WeVNCBkFYyxOcsuCCQO0kA
h6ti8LJhBcm8L3GWOh+NRtqCkjyzXOlVM0np8j6Tc4hC4Zf4cu6g6g3LxHpjVwjN
XbKyYrPLnoyhKpcrJMrNxYdKrQA7ZC8kFd+R2+siNrU38F8LTWO0lve8STxWOLAQ
lOqkScF3U7SaKjjHa5uPOKSziNX3EaPHZ0/Ny4zau0xTVJ9SS0Q2N69F2x4RZMiz
R1XguF78ywbD3MTGoxUsIJJNIzow7dPA3HodpSDmucweHtZspqDW7yrvG0A/cylC
tDUFPlKH1SCI82ys35cATrrwZ7k4ZeBL7bYy8z52ahQuhJYNrFHdQ6rf27JestMP
VQ4Zu3plVkmGbTf4G260ANSPMf7s2ic9ydl22BGJT+rsNU5xhiZQKx6jtCcRNhVf
PC/vx3XVDYGll1PG3a9LpOh9P0bx6ZuBZxisRdvpQQ4DUQDsm+GGOkB/1ioI+uMI
duElGFiM066/0MGfuV0u3T04clD/4OIz2qBN6jOpz02LQNBymz6V08R0lbBGZaNp
LP2GBbDYZDJjqHfusGb6Q9mT90LQ6Yn7k7Mjx3+YjLesUOPAHgEOWr2ytD7MRl0i
Fm87SKodoKUOCLiO8Jo/
=i9lE
-END PGP SIGNATURE-

php-7.2.34.tar.xz
SHA256 hash:
409e11bc6a2c18707dfc44bc61c820ddfd81e17481470f3405ee7822d8379903
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJfdBT8AAoJENyf+NPuWvJ/4KMQALrAHu6YRwhslzec5jFHqfKO
c+Jo1RhWlAlZHBkUXXHvsrOwBBjzRUC2FITfsH6CyNXUhYTEp/XHg+gupQBsPeM4
ojYB+omauHYPgLgsvb7U0seqDKUzccIQdFgJkN7JxhjucTkdEiDmUsgkzgtbbtiy
R4j+N+/5m82VM0kmK5gc5Yx66mtvrHvYGZza3Lixvk1R/R/cDgcsF2ArOYggBqIl
IykVD6Yto2A4gUygJ8nObEPkUOQqTwXhvvHc9eqb3xXae4biRgzsdLD3/z6g0np8
sC9ZVweIf8o/htWYHQgzfmKty5I3yuqwlH1S0iPv4mnJ7aY6hi7XK/s7gypyHorp
x4ihe1ghMZvDKc03iz7QUx6jzpKonX+jX2u8Axgjyx/714ndlvrKCJYVBzwNXQUv
I6TTHOp+Ix9XyZnQP0HCfkiBjBL2PZPGiRtt6msjVhyuwTZt6elNEUBR77jYuaDa
UYu9i1RnIExPVo9wcnVFp3kq+X6/VTlFNso/elgFV0DArQrUWYxwT3Jt+LAIt4Sa
gDRiUpkTXxrmWKbDg9nJoeVTJ2sIUUt2hDRGPWDuAAVjeUKfeVY8k6AF6vPPCDfb
NPYw9XPHEIITd4R8DRC+A/Zy4rzi+e1yG4pZEdGurwSzRcIxdA5NgKzg/gI/zt+o
kGNNHvRhUX6YL0d4+Mao
=KOFn
-END PGP SIGNATURE-

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

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Nikita Popov 
On Thu, Oct 1, 2020 at 1:44 PM Rowan Tommins 
wrote:

> Hi,
>
> On 1 October 2020 10:36:20 BST, "肖 鑫鑫"  wrote:
> >I commit a new request path, the request is about execution opcode file
> >without php source code file
> >this RFC provides similar to class file of java and pyo file of python.
> >patch is: https://github.com/php/php-src/pull/6146
>
> I'm sure someone who knows the internals better can clarify, but my
> understanding is that PHP OpCodes don't currently have any stability
> guarantee, so you can't rely on a binary taken from one version will run on
> another, even within a release.
>
> In order to be useful, this will therefore need two things:
>
> - a header in the file identifying the engine version it was compiled for,
> with an error raised on any mismatch
> - a policy of how to manage that version number, and how users can know
> which versions their binary files will work on
>
> There's probably a limit to how stable we can (or want to) make the VM, so
> these files will never be as portable as a Java class file or .Net assembly.
>

This is correct. PHP uses the "system ID" to determine whether it is
possible to reuse compiled opcodes. This system ID is used by the existing
file cache.

The linked pull request however explicitly disables this check, which is
not safe. And with that check enabled, this feature would probably have
limited usefulness, as the cached file would be bound to a specific PHP
patch release (and to some degree to which extensions are loaded).

It would be good to know what the actual use-case for this is. If the goal
here is to distribute pre-compiled PHP code without the source code, then
this is not going to work without making the opcode format stable (which, I
think, is pretty unlikely.) If the goal is improving cold startup
performance, then I wonder what the benefit over the existing file cache is.

Regards,
Nikita

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Rowan Tommins 
Hi,

On 1 October 2020 10:36:20 BST, "肖 鑫鑫"  wrote:
>I commit a new request path, the request is about execution opcode file
>without php source code file
>this RFC provides similar to class file of java and pyo file of python.
>patch is: https://github.com/php/php-src/pull/6146

I'm sure someone who knows the internals better can clarify, but my 
understanding is that PHP OpCodes don't currently have any stability guarantee, 
so you can't rely on a binary taken from one version will run on another, even 
within a release.

In order to be useful, this will therefore need two things:

- a header in the file identifying the engine version it was compiled for, with 
an error raised on any mismatch
- a policy of how to manage that version number, and how users can know which 
versions their binary files will work on

There's probably a limit to how stable we can (or want to) make the VM, so 
these files will never be as portable as a Java class file or .Net assembly.

Regards,

-- 
Rowan Tommins
[IMSoP]

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

[PHP-DEV] Re: CallbackFilterIterator is leaking memory

2020-10-01 Thread Michael Voříšek - ČVUT FEL 
Hi, 


if the dual_it is hard to fix, can we fix the memory isssues using
WeakRef like here
https://github.com/atk4/data/pull/737/files#diff-cc2c8bc61e741e6f1b07d0076c5036c0R51
inside php directly? 

Why are internal objects not correctly linked and GCable at all? 


With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek
ČVUT FEL

On 23 Sep 2020 11:28, Michael Voříšek - ČVUT FEL wrote:

Hi, 

can someone please verify https://bugs.php.net/bug.php?id=80125 and fix if possible? 


With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek
ČVUT FEL

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Henrik Skov 

Hi list !

I would support such a feature as well.

I am working on an implementation that would integrate PHAR support and 
opcode cache binary files
(so that you could make a PHAR file that contains binary (opcode cache) 
files)


I am voicing my opinion here because the current PHAR implementation 
does not work with binary (opcode cache) files.
(The problem seems to be that the PHAR extension directly extracts/opens 
the phar file directory, compiles the file into opcodes
and then executes them) - But compiling a file into opcodes that is 
already a binary (opcode cache) file yields garbage...


So if this feature were to be implemented, the implementation would have 
to (in my opinion) solve this problem in the PHAR

extension.

The way I have worked around this problem is to implement some extract 
functions (require_once_bin(), require_bin(), include_bin() and 
include_once_bin() and then make sure that autoloaders used in inside 
the PHAR use those when reading from/including from that PHAR file that 
contains opcode binary files.


/Henrik

On 01-Oct-20 12:36, Michał Marcin Brzuchalski wrote:

Hi,

czw., 1 paź 2020 o 11:36 肖 鑫鑫  napisał(a):


I commit a new request path, the request is about execution opcode file
without php source code file
this RFC provides similar to class file of java and pyo file of python.
patch is: https://github.com/php/php-src/pull/6146


I had exact the same feature in my mind and working implementation few
years ago
when PHP 7.0 appeared on horizon which didn't get a Zend Guard support.
I like the idea a lot.

One risk I see here is people putting whole framework or apps into one PHP
file before
calling `opcache_compile_file` to produce one big binary file.

Would it be possible to move this feature to separate function and pass
iterable list of files?
I am not sure if with current OPCache file format it's possible but if that
might reduce amount
of steps required to produce one huge OPCache file which then can be loaded
by interpreter.

Second thing worth of noting is that PR examples use CLI SAPI and lacks of
examples how
FPM can load it. Would it require at least an index.php with `

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

Re: [PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread Michał Marcin Brzuchalski 
Hi,

czw., 1 paź 2020 o 11:36 肖 鑫鑫  napisał(a):

> I commit a new request path, the request is about execution opcode file
> without php source code file
> this RFC provides similar to class file of java and pyo file of python.
> patch is: https://github.com/php/php-src/pull/6146


I had exact the same feature in my mind and working implementation few
years ago
when PHP 7.0 appeared on horizon which didn't get a Zend Guard support.
I like the idea a lot.

One risk I see here is people putting whole framework or apps into one PHP
file before
calling `opcache_compile_file` to produce one big binary file.

Would it be possible to move this feature to separate function and pass
iterable list of files?
I am not sure if with current OPCache file format it's possible but if that
might reduce amount
of steps required to produce one huge OPCache file which then can be loaded
by interpreter.

Second thing worth of noting is that PR examples use CLI SAPI and lacks of
examples how
FPM can load it. Would it require at least an index.php with `

[PHP-DEV] RFC: execution opcode file without php source code file

2020-10-01 Thread 肖 鑫鑫 
I commit a new request path, the request is about execution opcode file without 
php source code file
this RFC provides similar to class file of java and pyo file of python.
patch is: https://github.com/php/php-src/pull/6146