Re: [PHP-DEV] PHP test coverage
Hey there, On Fri, Dec 8, 2023 at 12:11 AM Vinicius Dias wrote: > PHP doc article about writing tests [1] mentions gcov.php.net as the > source to see the coverage, but this address is not available anymore. > The code coverage report can be found at https://app.codecov.io/github/php/php-src > I believe this should be updated to show how the coverage can be found > so people know where to focus their efforts if they want to contribute > with tests > I will have a look, the page overall looks like it could need some love ;-) In the meantime if you are interested in writing tests, I once wrote a blog post about that topic at https://dev.to/realflowcontrol/growing-the-php-core-one-test-at-a-time-4g4k /Florian
Re: [PHP-DEV] New "PECL"
Hello Tim, On Wed, Dec 6, 2023 at 9:05 AM Tim Starling wrote: > Have you considered keeping the support matrix in the registry > database, instead of in pecl.json? Then it can be updated with new > build/test information after release. We do it for windows, used by pickle, you can see one part here: https://windows.php.net/downloads/php-sdk/deps/dllmapping.json The other parts being part of each extension. It could be achieved similarly for linux package managers, maybe maintained by them directly. A few years back, I made some tests on windows and linux using https://conan.io/ and https://vcpkg.io/, they both work on most platforms PHP supports and also have cmake integration (php build using cmake has been worked done, very nicely :). Having maintained these parts for many years, dealt with 3rd parties (developers of librairies, distro packages maintainers, etc) as well as dealt with many end users (php developers), I must say I would absolutely not start to define our own things but rely as much as possible on the well working existing solutions. On the same topic, npecl's requirements (why not a RFC/proposal btw?) are kind of out of sync with what I have seen and still see. F.e., doing it outside the composer ecosystem will most likely create a niche and not a wide adoption.There have been a lot of efforts put into similar topics since 5.3 and a lot of learning, it may be a good thing to learn from them. There are also tools now available to give developers out of box tools to define whatever environments they may need and switch between them within a click or command line (Laravel community created a few good ones, mac for the biggest one, and other platforms), having them rely on php's platform for the core and non core extensions (including their respective deps) will be amazingly helpful. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP 8.1.27RC1 Ready for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello! PHP 8.1.27RC1 has just been released and can be downloaded from: https://downloads.php.net/~patrickallaert/ or https://qa.php.net/ or use the git tag: php-8.1.27RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.1 Please test it carefully, and report any bugs to https://github.com/php/php-src/issues PHP 8.1.27 should be expected in 2 weeks, i.e. on December 21st, 2023. Hash values and PGP signatures can be found below or at https://gist.github.com/patrickallaert/d2a66fffdcef91c57040b3ecb9922a8a Thank you, and happy testing! Regards, Patrick Allaert, Ben Ramsey & Joe Watkins php-8.1.27RC1.tar.bz2 SHA256 hash: a57aa1eab465a12383f5ab93a9fb3a108ea26466857cbb522ab17fedf6753127 PGP signature: - -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmVvLzAACgkQGZ+d/vb/ uv0gAQ/+LtFpnp/qMt7QMqX3/ZfPH9nhVIDNHKYrCqQD+4vx+gAWe74NhMPkoIKK 3SWJm/65RN7oZUprS1DAOMkrsdeJ4w5IJGbfh9VhIXCL38wWE/tdnzcX6E/5GVo3 5cLwQD2ovcBb/zP0YIzt/q1Cfu2ua20Z9A58uLUDpV7riuCaQ6u/0dedK5UODkYF 1/U9Ho+wdS/iVf6hzZed2POBMmhvwFmJyoNuhrjxSAdXNl3UkWOF7Th40owkDLNY ErGaJLs0j0gfiXjA4IsZadcfgT5q0X8Y1WPUAQy5UQYJd7OKysUc7ReBk3iYmGXo KLTz0FN5/uB+YrV+f5MPdODMquQExj2c4JpjoKF+nWCXPw+S6q4CSwk7HPj9LVfC CR8tgssIyaV+HSFmvtsGmvq9lKCkLT3DQgyGkzbalQtTLxEhjVwt/ZpNVDkAp3J2 7Nz8Ti5PLFI/NzBVJ1J/mgUYY9aC0iy13yEVH0oDSM6cfjiOm3W+676RJmE63uyH E9Gu2fGXRyKA0MMAL602twV39Tiw6wziXL6GBbZFGxzE1qVBqLblu0Rzi2fiRhux 4dz+3lP/zw4OhTwnPv757TmkdSppOIxhhA+V+EQW47kZXGyFeiAYpLXUYoMEHzTF 9oqmIbNOdJVJY8ksviN9zbV0qlHx50BQCrxf4qQoOhB6Q3EBqSo= =E7M0 - -END PGP SIGNATURE- php-8.1.27RC1.tar.gz SHA256 hash: 402bd10ba9362809c3d9569c4eddcc9ac01aa3ef582bc80839fcd7c235dc6566 PGP signature: - -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmVvLzAACgkQGZ+d/vb/ uv1c1RAArcjhQ68fdl50+k8eMvEacxJrCQKaW53P5+JRkdLYF9RxCPgCMdlBurS1 PggT24TC8fLLGR1mWJ1QQTRIw1n7HMkxMe7cdsBLhoM213ucnYvNl7MniX9ovcP4 aHcUQSmrgnYBuWfBEK8UPoKgaOOi6MV4QFRHt3i0UnHuzGUMYN4dizKFBBqckojx D0DqhGMPLDO2JvpSOoIhMa2XwXwKIxwPEh5/ZTYVCkyWRQMUSsZLam/z6wMeWB4f UHjkwXbVxZxjF5fb3xIXBMbgNESntpPIkGQ39txIwEG+9YGAnbFIjCLaT0FoZ8pm qmSWGx3n46bCw56c1TYLYV7TBzDVp+t73Prqd1qzSU/LiZ9fEZEn6uuXwR1kL9we 5gG98yJjEJl9Mk7g9V2GkZ5Uu5v28dr388vqOii3tZmN/Uj7WksQYa6HO5MAcqOt vA4EVP4xgrbfCDf3Ryl2Ht/LkKqbhMtMc9YHNX4LhxSEq28yB7dcZ33WlDpJqZrz Vxao5y4z/yJPujgEKcztkBSkxjENeLgpR7YdCGIi4aPRxXqQsZX9QBb4ezGG+omx uNObASF+p571Q6SE0WtVWXV9dG77SwD/y8j2dmXCH1WRTDqldNyZAUOHutqzylI1 igiSYMacIjMp5ZgOvTwlPpzMruT6KsTkb1RaGDCQiZZJs3aVvS8= =4LuD - -END PGP SIGNATURE- php-8.1.27RC1.tar.xz SHA256 hash: 8e1dabce2b7119c5b8753b9303c0944ebea1dec2a92421fd95e4273084a5e0cc PGP signature: - -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmVvLzAACgkQGZ+d/vb/ uv2ZwQ//Ze6MGtRrU5dz3h0PRs7WUO67Os2N0JJ9DaiBo1nmKaN6zEUYjrCfw7M7 9lAQdkolbjzL7/vLOkYssolBVZVCnDgKgqdUn7UiqOgqsgsyo5OEeexQF/0hDKpH B1Ea66jx+9eeVlMzGUfyeEl6KEqhYDIcz4M9InDmUfIsgTuPmCA4GfMpIg7+fpde rpUlxtCaNj+LGIzNhlg7vEky4vmfh0yG9FJF3Z1b66q4N5jxKdaIG/f0NqVsRbWX IFxboka8LdjcLoPl+HLGFUPAVG7Zoa2zVKEULS5ZnhhvtWYMAbrjhGxQ+mVVLpRh n9GKmC+M9W2qL5C6Wf+Zh4VZN6552DUKxcYd1kUrqmt7aCd/p1iIJ9WUQbWuo4ui iW5REdpp+404ceYjdPzzdICoNUyGH8mZIVMs9kRcFdciMOfb25PCboWfIt65zA36 HiOXRkkHuHXDkOZZUagNQaw+cMATr44Bp7j/4LNbDiNBEXSX7UTaNq4VlHT+/Zyx U4Dnlm4vHJgYaM7CdEmwgXoNXQK36gtwU58f8588dE1Yj61bZGkTLXc41n3lCD5o wxd3CzAxS/2F+TrICXIf04cvsphkcY4r1GBBcrSvacYcjw0BHTswX3Bd4BnZSJT1 QozJ/bcEmqH+OyuHkaG7HGHmLdean+HKpDW29wreJuPYhoN2Lp8= =VPrC - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: FlowCrypt Email Encryption 8.5.2 Comment: Seamlessly send and receive encrypted email wsFzBAEBCgAnBYJlcnn0CZAZn53+9v+6/RYhBPH2kiOPvBZm5aXM1Bmfnf72 /7r9AABQgA/+PpVmQbTa48hHEFaqB63PPeqiDlPJSHGwJGOi6JrDRz9+Et1W /IKhuz5ScmmZEdVsjUwhsKZmMu/8huNPbPWGxA5D7igPbvYBOhbt9+p4AWLQ W4/T/IhzD7rSlaXalybxvPAZg74Evxwl/o342ep94o0ahMTm775HBjkZvgdJ +3G6vXuwQ5j3mcx9Q5bksbeEQm9yRi8kgwLGvBUFJ0X3c3O6VcFsQEWcUn3+ mzv0BETe4VnyKhd1j3MZkAbr5IgmK3hY8+svq+kO3U4lzxJ0xfSXfOl4KLam xei8zNpSoH/2ivDSJjGk4bn4nmAIauAzhe39K5fsabemCRJ5OsOHBuKtPb+L BLVLJxiPs8a8VhuVuDwoYkrOotW3uqtOjZ1pnuO9NiQ5NhN7zZyoGkZ3Q3B0 8ro0LBWavWo788cmuYNtTbBWZLoU65CavLsiDSdrtAZZgNPjEdqDvAm4YZQ+ eop4PWnwRB+3xuMN0Sm6nanzhZ7tvfZWMNaZBXmTMkAfWfnKM+ByEjWsq4k1 jyiI5U3Z+JqzR2NIZyp3XXGoySANDhcA23HMPceFwkz3KKXNo5TTmfk2WNLj ukWtos2S1lSbY4r09smr+yafAsPjIK0QWD20f8YwVW4w32OjpSZTJYfRTAsu 8RSzXUNpf63jhJNkTkiPVCCl9u9RXInf1q8= =FSQV -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] bugs.php.net still active?
Hi Aleksander On Thu, Dec 7, 2023 at 9:22 AM Aleksander Machniak wrote: > > I was under impression that bugs.php.net was supposed to be phased out. > I.e. made read-only or something. > > https://bugs.php.net/bug.php?id=78628=1 proves that it's not the > case and I'm receiving annoying spam recently. >From the GitHub issues RFC: > Per the above, bugs.php.net will remain active for the following purposes: > * Reporting of security issues against PHP. > * Commenting/updating on existing issues. https://wiki.php.net/rfc/github_issues#bugsphpnet Security issues have since been moved to GitHub. However, commenting/updating bugs is still possible. IMO it would make sense to limit this functionality to admins, and encourage users who want to add context to create a new issue on GitHub. It has much better spam protection, and visibility will be higher there too. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()
Hi all, Voting is now closed. As a result of the vote, this RFC was rejected. (7 in favor, 8 against) Therefore, as stated in the RFC, the following pull request will be adopted to fix the bug in `round()`. https://github.com/php/php-src/pull/12268 Thank you for all your votes. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP test coverage
PHP doc article about writing tests [1] mentions gcov.php.net as the source to see the coverage, but this address is not available anymore. I believe this should be updated to show how the coverage can be found so people know where to focus their efforts if they want to contribute with tests. [1]: https://wiki.php.net/doc/articles/writing-tests -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP 8.3.1RC3 available for testing
PHP 8.3.1RC3 has just been released and may be downloaded from https://downloads.php.net/~eric/ Or use the git tag: php-8.3.1RC3 Windows binaries are available at: https://windows.php.net/qa/ RC1 or RC2 have been skipped due to errors made during the release process (my apologies). Please test it carefully, and report any bugs in the bug system: https://bugs.php.net. Hash values and PGP signatures can be found below or at: https://gist.github.com/ericmann/8559a5375f293f0538a0bd8637568c17 8.3.1 should be expected in 2 weeks, i.e. on 21 December 2022. Thank you, and happy testing! Regards, Eric Mann, Jakub Zelenka, and Pierrick Charron php-8.3.1RC3.tar.bz2 SHA256 hash: e0b4c70e833f5ade24641e7d70c7e8c413584fe2cb554b89e42d6a1493218ddb PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmVw2jYACgkQvsVV4ioU NVOu/g/6AneyQtXfeLbnpDo3Wxj0no5GmT7YsTch3V+eH8dkFvlRkX5lzq6mtVGM cUmzXN1tQHlqXRzOAIX1+8iknnDY1utMvQEo2UsmhbwFNey+dFTguSjn30Es68QI jXKpTET/Thvppw9bRoGPg52+xOwgnPz5LDWykaqqdHqifvuXwpzTaZKLAQbE0gXi BwGULsRDlgPMTZD6p4qdd9JUeLWdFaZYvWZkk87PaLdAevVjWWD8pWU0Rh9eDajj vqckxO36RLjfPanbMO4tKFbIsaAgrXHdqKXzLS6s06tQftIY/9fd7rwH+IeN+Txm UA8Y7C7p9/HB0toeNR06Pv7w0vm3yAf8W9fYfCPlr/UYLvxBZ4qEgnyoR2yU6Vef D9paMtyaQSDZNcZKI0QkAz7etvqLMLgwgQQprotD5ZqAFGGQWVEsIYe3MUkjnNQa Levln1sHNKFrHueibTrQK0wFuwVca7iJiFEUKafAV4P+xT3Bq5Ki9taVxyckrT75 ciO2yrj780ElO4Zsbh1aODkA9LrR9qA4F5ltyJmcLWtz2wlHheDIvkcCfHcNa7+m jVxL8AUW7ihVuMWIhNENMxstIMsdtmCjBpinptqLlb8vgmgSm37sgqlnvDJ+L83l rlJdUC0TN4hNU+UzlUkvAZ35EaSpPpBchwCmWuXdzPE41PD9is0= =6xkV -END PGP SIGNATURE- php-8.3.1RC3.tar.gz SHA256 hash: b548b25e77e6249a8041d96ad47eb6ea41d19dd281f3a01cdf0c954fda5bdab2 PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmVw2jYACgkQvsVV4ioU NVMFvBAAvuhYIQHgqZ4bUs4RP4aJcnlrG7o9zR/1LvLJeLwsoixTwygpVKpTL4Eu 6xuf+yltk+wSYh+qDWIClClVBpX2YI3mD0gLmHCE4unSn7AwlqWNBc/47WLqOtzV WIPU00MAhw4sRx7rUMPOacRSuY6wHp0KBinU3WCU4HTZbTVNDmch8gv1SIva3oWx +hdXOz2GuOnV9Emi8Cq7TgSwEey0/yl6XHhiZzG4wE/ZUwLW+LyLaC9v0B+mCOzT rRgzvPEciL5u3FuEmLIw/h2V4wM2nHRDYoZ85KAQUQ6b8k4KQV30xvgKYAx5VI+G 2zVT/hog0bT2Q81TW+iLUUo4s7p8DZRpSAEbr8tLsHL/kVRkXh/LJrm0pqq4PHJw N4Xj+9ntKfhrAMkZDpnlcy4fOBr2Zpr4n3m+lyKCwAJ7qT2x+57V65FPfEl4vcNT 4vqZc/gPcM2DCg8unGCb2ZtBUna1RefWUcm8VzLH3qTVkFWJHEvxZlJpZTCNbsPb ogkcKHP6hhEo2ip3t62M2M0qc2+ztr9VbTQwhd19zA9Gp3LNKtMZi+TKOx+3/DN3 /Zf+iEeQkISMfzfuK1s+RanMCNebEO/Y/D/7cN6LO0GzQEE1JX0KqvZ0Xd8s7nn/ /sRMr0JkUc5k0EgXEFjZqfi610sSdKCgCYI5HvUerf5bXwICCEI= =jUHe -END PGP SIGNATURE- php-8.3.1RC3.tar.xz SHA256 hash: c779b9a927cf181cca6c24ef7f53ca799b07e837d19f62807ea5465014ec62a2 PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEESx/A2d+SMhztn2FdvsVV4ioUNVMFAmVw2jYACgkQvsVV4ioU NVNb+Q/+OgCDFbdCPshnGUWaDj+1PVvIqJbusVu3/UDqN+bl88HR72c8liWBk0jB 7jvfV9Tdk4hnciICjBZsOkir/fU0SP2/+TeOY2cAHuw30BiEg/v5WybTkWaUHFpv WsXOXyV6/r1Wk0egP5OpoK6uHBrD+gkXQAXe3D6k1+bUzpMQbB0Llfq6WAY3FGDw BwUa04gi5RWugeX/OzULT2vDfHFNFu6EW2mT/4Yrx4wsbtDqMnm9Ca3Cl+4KLQTs m7B7PnHaNufw5sWngahk5cJgCSyPBTHB2EuqbXMSayu3FQU/SaHZXXRgXR7AkiQT 0cJWBvVwXcO4/9geFPVmcsQGvSDj+/66TOUG0AdAroFqS2zr3Jxj+xxCPTNCTiFB TE2X1X9hW62eAupu5ft5iUuE2ucNV4kSykUnWVVUMOOAp1/Rv0A6yaRKhmFJTkUh 3a5EeBbfDfl5qzP4FjEynMprSYnRsy10vrgh/LswFjGYdxKVSO77io+3PDylemI8 2SlNw/r8d+cccdMya/JPTgVX50LU62qZE77vpPpr1sVvek0SghpTSRBHZJFtyMJM 6qF38F4TAO/SgJ0/VGsqfM/WwUb2FG0B+ao+gl37jQqoaXhFOC50uMQWmuDk57pf +LThUlItCZcnjGyTZnis42OOv26zEov2xw5WDwt6R8qez2dqvAA= =PSeA -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP 8.2.14RC1 available for testing
PHP 8.2.14RC1 has just been released and can be downloaded from: https://downloads.php.net/~pierrick/ or https://qa.php.net/ or use the git tag: php-8.2.14RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.2 Please test it carefully, and report any bugs to https://github.com/php/php-src/issues PHP 8.2.14 should be expected in 2 weeks, i.e. on December 21th, 2023. Hash values and PGP signatures can be found below or at https://gist.github.com/adoy/b0daf2b42dd7aff34f2b611619dc3adf Thank you, and happy testing! Regards, Sergey Panteleev, Pierrick Charron & Ben Ramsey php-8.2.14RC1.tar.bz2 SHA256 hash: b34d001d7d2d1f59e48441cacd8de10c84a140be3b3659ef0a6697a46adc66c8 PGP signature: -BEGIN PGP SIGNATURE- iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmVvguURHHBpZXJyaWNr QHBocC5uZXQACgkQKGrx+Yl0adzhoxAAhzDVAjkFw3YHIVR2c6St/hJlQNPn7Blb KMagANR+cTdyLsV60+nrHjvBLNz5EYdmjGwi3jU0H2oVKWetZSW3H6Afg7p+FGC2 MDAifvhvhH9y7ikwKixTmKG2QdNNZ0FRa0g16cnBOwS1vkPNOo+o60mzqjtBXCbT Ekg6AWaP9/Qla27terNXrvB/MDzJSD6g48J+EUJ6Jz5Jh/BHdxxE+cQhFQ1T9KBF ipQ55BZ6Uo8MCXEoIrQweglzLAtpFC3gZRU6fzrS5dI8K5Hpr10jl66aqFO7vQHF ZtnBwAg68hqJtflnj4s3Y52cIBvRhXo8IqEprM+bUUYR4bV5zI2AIEW4dNbFb772 PB9nB6fR95WzQCfkHnUI+8ewpiH2jeFfqCU+4qyeLtky/T5FD2jJC2Y8eWrJcz9n Cysvyu2WPRiM6rQ9D4Tl00vaJtWJyyZuNEwbiPfrkL3YiA1Y73NFA6H2ZuZnUxzq gS6R/xlJYU+MF8ef2JW9sdrg21b1yPmGiaubRnoVQPlIFcImd6usy6awu9fvp8fJ V59KaA9KNvkQK1RsswlBaVH1iNDzq3Q+TwzWAg1qHPr4mAp7mSQZwZb17T0xfdtR 0j/W86FPqrJCSVP/8jfk/koqQ0/vZFVRn5G1hSiPk2g++/XFzPAkpd/hjPod/ROs EcJ8kpgcT34= =TMC5 -END PGP SIGNATURE- php-8.2.14RC1.tar.gz SHA256 hash: ba2df909626976aec27341625c69841988b8af48a6fafd53014c0ca6a366082f PGP signature: -BEGIN PGP SIGNATURE- iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmVvguYRHHBpZXJyaWNr QHBocC5uZXQACgkQKGrx+Yl0adxE0RAAovl2o/+kJOv0LM6Ef1jnQMRnfx0DvV2Y 2KQO2qQITKQhav9Vm8thF7nyPfMK2SZPRiaWNiMRivlEq6MDz7noDH5ItUYoJZS5 YNmwCHcONzJLcqOLgRMi/XJx6VOkBUCtuijnKq+TNyfFU5CigHkjCmWgSWZJBPHx 3+netaLwIsTGycmw/TOavgd0raKXuDhOSnAqOXFwxyS+HAlJDwxUSRD5i0bryTgG wzjAB9knvIz5xOsDSJWqzKTqYZq6EqeApTnQCirGUDyDFtHTdjrcg+2Z84kFIpnt 8HDbmpgqHJpBFUXHPYrkHwp0TPw+BQbSv2UxaUzB2zv4dy/0U9BrZkyT9SbCFQdh xIa0ki/1PizP2JDShAN4GT8xdH3/TnG6uRvx7b9U+rP3Gxt4lBf5CxGwiOQBnAxs yR/rHNe8PSPKFPvMRik60YYXQBZgHVc0dKytUBd/qsj5t8nGYAiGvKleOdiWkoW9 L5z1PKM1i/pq9bljUBTTh4ph3QtctRzoWraL6wpuScnIE+I3u7+6IvkAEmer8t+4 s+/DcYVSBNQIBEToElLu5JEKWF6N7YbllrjMAwbmVzFUqBiFJAjQIzu3tqnxY9zQ 54niIP+06Fsf2Q5O+/B6Yw8F4u1JsIbT1rGRWHDluN/ktgDSrt8+Ic1FP1gDLtn/ hwcthLZV5X4= =9/S/ -END PGP SIGNATURE- php-8.2.14RC1.tar.xz SHA256 hash: c1677fb15c9bbdedd003fa29d0b1cee2b6706ec8cc04be1e6d01dfc1dd174199 PGP signature: -BEGIN PGP SIGNATURE- iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmVvguYRHHBpZXJyaWNr QHBocC5uZXQACgkQKGrx+Yl0adzyKA/9EoEZqQ94PPhhad7UhYBSV8npFbslNuVO JBapvr5ywxfWJvgy68iPmRoDAmG0+EOy1HDufEGwho2PSAVZHTC57yV7eKnHeWLI 63rwEwfenfu5Pn3biWuGxJEJnCb7B3wjLdhqVFiLJ7XLOl0xAYYoAsMOBIGByqvU ET/1Un+uWkrsPVfs4bE4H9o9hgF3QHqqOU09e7jTVafqR4Q/B7rS2YBKANK5wDk2 NtJ1o9bA6/TqNlMnye/v+aBdsKgxOo60q/YsfQXgopSDVWQra8A5CcNcSwuA4qoa VcK1g0MF73h4eymfhqjkEqeRtGPHR4L7tNn+zLSlAzjSyJXiRktyYZuuAqHiyu0T SaMQBH2Fxj9mSc4j0f/RCjw4NAhofu5bMoj0RmPL0OzOzp1LtD+BL3L645iYA92j g1TMJBJnrk82iHo2rwHAvk3xZVoz3dRBpP5FVeTuz+1FAnBqoQql85O+49dwxZNU vwsZEy8+lHpKOjbIlTjfJPGbQTKIm1gkBkqY1+S7NtdVS68q4N/o1x3IPHMc5v3t AyYJB9uery+95QxmW/CrZnL7SlxCwfNWS/13q4ck3fPKLk6g7+fzCwul7wcsy7Az wTY4DS5BKSE/GqfoZdQNjMMZlxEsYUOQDYh9ZuL4vF0YytGGFQU1MPbyHzRApJ1K JEsWYHkO31M= =sauB -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hey, I'm not sure if this is bikeshedding, but the concept of parsing bodies for non-POST requests lands really close to a proposal for adding a QUERY method to the HTTP standard. Draft: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body Discussion: https://github.com/httpwg/http-extensions/labels/safe-method-w-body It's meant to address the recent need for complex querying (GraphQL / Elastic Search) that necessitates using POST but loses the default caching of GET. I think this RFC could serve as the groundwork for supporting QUERY if it's extended to other MIME types in the future as Larry suggested. But QUERY probably still has years to go before there is a consensus on it (I think it's been talked about for 6+ years now) On Tue, Dec 5, 2023 at 2:29 PM Ilija Tovilo wrote: > Hi everyone > > On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo > wrote: > > > > I'd like to announce an RFC that proposes adding a new function called > > parse_post_data() to expose the existing functionality to userland, so > > that the mechanism can be used for other HTTP verbs. > > > > https://wiki.php.net/rfc/rfc1867-non-post > > I took a closer look at RoadRunner regarding file uploads and noticed > that $input_stream will not be useful to it after all. RoadRunner > handles files directly in its Go server by parsing the multipart body, > storing any files to disk, and only transferring the file handles > (along with any post data) to the PHP workers. New SAPIs could instead > tweak sapi_module.read_post() when handling a new request. We can add > these parameters if somebody can present a valid use-case, for now I > opted to remove the $input_stream and $content_type parameters. > > Please let me know if you have any more feedback. I will wait at least > 2 weeks before going forward with a vote, as this is a bigger change > to the RFC. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
RE: [PHP-DEV] Filesystem path APIs
> The feature request is about the following: > We already have some functions to work with paths in PHP, e.g. basename, > dirname, realpath. > We do not have some common path APIs that you can find in other languages > like: path_join to join paths and path_normalize to normalize paths. ... > What do you think? That would be a welcome addition in my book. -Jeff
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Thu, 7 Dec 2023 at 06:36, Alex Pravdin wrote:
> Hello internals,
> [...]
> GMP:
> - Workaround: implements the GMP class that allows basic math operations.
> - Requires using separate functions for the rest of operations.
>
> - Objects are always casted to true, GMP(0) will equal to true.
>
This is incorrect, GMP object do _not_ support casts to bool
See https://3v4l.org/LHpD1
> It works the same as "float" in terms of its usage and type casting except
> for one thing. Float value can be passed to a decimal argument or
> typecasted with a warning like "Float to decimal conversion may incur
> unexpected results".
>
> Decimal to float conversion is allowed and smooth:
>
> function f (float $value) {}
>
> f(0.2);
>
> f(0.2d); // allowed with no warnings
>
I disagree with this part, floats can not represent decimal values properly
e.g.
$f1 = 0.1;
$f2 = 0.2;
$f3 = 0.3;
var_dump($f1 + $f2 === $f3);
will return false.
As such, floats are not at all compatible with decimals.
Moreover, the whole point of adding a warning when implicit conversions
from int to float happen was to be able to warn before elevating the
warning to a TypeError.
Therefore, introducing behaviour that warns instead of throwing a TypeError
is already a no-go from my PoV.
> [...]
>
> Literal numbers in the code are converted to floats by default. If
> prepended by the "(decimal)" typecast, the decimal result is produced
> without an intermediary float.
>
This behaviour is rather suboptimal, I'd rather have literals be decimals,
as decimals to floats should always be a reasonable implicit coercion
considering we already do int to float.
> New declare directive "default_decimal" is added. When used, literals and
> math operations return decimal by default instead of float. This is to
> simplify creating source files working with decimals only.
>
Please no, no new declare directives that affect engine behaviour.
Strict types was already a mistake because of this IMHO.
> New language construct "as_decimal()" is added to produce decimal math
> results for literals and math operations instead of float without
> intermediary float:
>
> $var = 5 / 2; // returns float 2.5
> $var = as_decimal(5 / 2); // returns decimal 2.5
>
> This is a kind of "default_decimal" for a specific operation.
>
Again, this should return a decimal instead IMHO.
> If mixed float and decimal operands are used in a math operation, decimal
> is converted to float by default. If "default_decimal" directive or
> "as_decimal()" construct is used, float is converted to decimal (with a
> warning):
>
> $f = (float) 0.2;
> $d = (decimal) 0.2;
>
> $r = $f + $d; // returns float result by default
> $r = as_decimal($f + $d); // returns decimal result with a warning about
> implicit float to decimal conversion
>
> All builtin functions that currently accept float also accept decimal. So
> users don't need to care about separate function sets, and PHP developers
> don't need to maintain separate sets of functions. If such functions get
> the decimal parameter, they return decimal. If they have more than one
> float parameter and mixed float and decimal passed, decimals converted to
> float by default. If "default_decimal" or "as_decimal" used, float is
> converted to decimal with the warning.
>
Messing with the return value type has already proved controversial.
And as I said previously, I am dead against having implicit float to
decimal conversions.
Making the functions type generic is something that I am fine, however.
> The new type uses libmpdec internally to perform decimal calculations
> (same
> as Python).
>
I really don't think we need arbitrary precision decimals.
I'm also not convinced using a floating point spec is the most sensible,
due to the rounding errors this is going to introduce.
The non-arbitrary IEEE 754-2008 specification cannot describe the decimal
123457.1467 exactly, which is frankly pointless.
Decimals, or more broadly rational numbers that, outside numerical
computations, that are going to be used are not going to need huge
denominators.
I've been thinking about this for a while, and I personally think that
rational numbers are just better than trying to support only decimals.
And considering we have 64 bits to play with for a new zval type splitting
the bits into a 32-bit unsigned integer for the numerator and an 32-bit
signed integer for the denominator should provide us with enough reasonable
rational numbers.
As any number that do not fit in this structure seems to be something
relegated to the world of numerical computation where floats are what are
mostly used anyway.
> All of the points above are subject to discussions, it is not an RFC
> candidate right now. So please share your opinions.
>
> I know that the implementation of this will require a lot of work. But I
> don't think this is a stopper from formulating the requirements.
> Sometimes,
> any project requires big changes to move forward. I'm pretty sure this
>
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Wed, Dec 6, 2023 at 10:36 PM Alex Pravdin wrote: > Hello internals, > > > This is the second round of the discussion regarding arbitrary precision > scalar type integration into PHP. The previous part: > https://marc.info/?l=php-internals=168250492216838=2 was initiated by > me before deep diving into the work with decimals in PHP. After 6 months > of > working, I would like to update my proposal taking into account my > experience and the previous discussion. > All builtin functions that currently accept float also accept decimal. So > users don't need to care about separate function sets, and PHP developers > don't need to maintain separate sets of functions. If such functions get > the decimal parameter, they return decimal. If they have more than one > float parameter and mixed float and decimal passed, decimals converted to > float by default. If "default_decimal" or "as_decimal" used, float is > converted to decimal with the warning. > > You are going to run into some very difficult corners on this one. For the last... 8 years i guess? I have been working on an arbitrary precision library for PHP in userland. It utilizes BCMath, ext-decimal, and GMP, depending on what is installed and what kind of operation you are performing. So, the functions that currently accept floats include functions such as `sin()` or `atan()`. These functions are not at all trivial to do to arbitrary precision. In fact, the VAST majority of the work I have done on my library has been to handle cases like "What do I do if the user wants 2.921 ** 4.293810472934854?" or "How will I guarantee the precision that the user requested for `tan()` in an efficient way?" Now, libmpdec is going to actually have implementations for most of this stuff that you can call directly, but if the PHP function `sin()` isn't capable of *outputting* a `decimal`, then this isn't really that much of an improvement over the current situation. I mean, it's still something I would support, but that's the area where some help from the engine goes a VERY long way. You're probably also going to need a way for a user to grab certain constants to a given precision. I would think e and pi at the least. I have a lot of experience working on this problem space in PHP, and am definitely willing to help. I looked into doing a libmpdec PHP integration several years ago, but decided that voters were unlikely to give it a fair shot, and so decided against it. If you're willing to try and roll the ball up the hill though, I'll definitely help you. Jordan
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
> > Someone tangential to your proposal, have you given any thought to > implementing this similar to how Python treats numbers? > Unfortunately, I don't know many details of numbers treatment in Python... In Python, integers have unlimited precision. I’m not sure how they store > the values internally, but to users of Python, any sequence of numbers is > an `int`, no matter how long it is. > > For example, this multiplies the max 64-bit, signed integer by 2, and the > result is still an `int`: > > >>> i = 9223372036854775807 * 2 > >>> i > 18446744073709551614 > >>> type(i) > > > And this is a really, really, really long number that’s still an `int`: > > >>> x = > 9223372036854775807922337203685477580792233720368547758079223372036854775807 > >>> x > > 9223372036854775807922337203685477580792233720368547758079223372036854775807 > >>> type(x) > > I'm not sure about integers, I mostly care about decimals :) Decimals can hold big rounded ints as well. The limit on the maximum number here will be the underlying library's limit. However, if we can achieve arbitrary-length integers, is there a reason we > couldn’t also have arbitrary length floating point numbers? > I'm not familiar with arbitrary-length integers so I don't know what to say here... > Below a certain threshold, we could use the system’s native int and double > for storage and math. Above a certain threshold, we could internally switch > to a bundled library for handling arbitrary-precision integers and floats, > and it would be seamless to the user, who would see only `int` and `float` > types in PHP. > I guess this could be a topic of the next step discussion after "decimal" introduction. Anyway, this is something I’ve been thinking about for some time, but I > haven’t taken the time to look into what it might take to implement it. It > sounds like you have looked into it, so I’m interested to know whether you > think what I’ve described here is feasible. > I was only thinking about decimals and I'm not an expert in low-level manipulation of numbers. Best regards, Alex.
[PHP-DEV] bugs.php.net still active?
Hi, I was under impression that bugs.php.net was supposed to be phased out. I.e. made read-only or something. https://bugs.php.net/bug.php?id=78628=1 proves that it's not the case and I'm receiving annoying spam recently. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
