Re: [PHP-DEV] Consider removing autogenerated files from tarballs
That would break lots of tools as it requires extra dependencies so it is not something that would could in stable versions. Btw, I do not believe that "it would require end users to install autotools and bison in order to compile PHP from tarballs" is valid reason to delay the patching of a serious attack vector ASAP. Regards, Daniil Gentili.
Re: [PHP-DEV] Consider removing autogenerated files from tarballs
Hi, It is also pretty standard thing to distribute configure files (which is the file that probably matters most). The current standard way of distributing generated configure files in tarballs is precisely what allowed the xz supply chain attack to go unnoticed for so long. I strongly believe all projects using autotools, including PHP, should switch away from this "standard" way of doing things. Also don't forget that we need to also provide Windows builds which are binaries so we need some sort of verification of this type in any case. Of course, build reproducibility is a very good thing, but when a user downloads a binary, they're aware that they're getting a compiled blob which might contain injected malicious code (especially if there's no build reproducibility); when a user downloads a source tarball, there's a false sense of security rooted in the mistaken belief that the source code in the tarball matches the one distributed in the VCS, but in reality, the tarball also contains potentially malicious semi-compiled blobs, not present in the VCS. It would require compromising the CI as well as the download serves happening at the same time which seems to me like an impossible scenario. I misunderstood your original message, I thought you meant that there would be some new CI system hosted on downloads.php.net dedicated to verifying, not the current GHA CI system, which is configured on the public VCS. If GHA is used for verifying builds, that would make more sense, but then users would be required to check the status of a github pipeline to validate that the tarball was not compromised (or alternatively clone from source and re-generate the build scripts manually, or simply trust the release manager, which brings us to square 1). Regards, Daniil Gentili.
Re: [PHP-DEV] Consider removing autogenerated files from tarballs
Hi, >The idea is that we would setup worklfow on CI that would run on tag push and it would call (authenticated https request) downloads.php.net <http://downloads.php.net> server that could do the actual build I strongly believe that source tarballs should contain *only* the source code contained in the VCS. Distributing "half-built" source code (even if it's generated by a CI, and especially by a build server on downloads.php.net, which can be compromised) defeats the reproducibility and transparency purposes of building from source. > For upstream packagers like distros I'd likely recommend using these tools directly anyway, and not rely on what's in the package. Distros like arch linux already re-generate the configure scripts from scratch, but I believe that no distinction should be made, *everyone* should get a tarball containing *only* the bare source code, without leaving to the user the choice to re-generate the build files, or use a potentially compromised build script. Regards, Daniil Gentili.
[PHP-DEV] Consider removing autogenerated files from tarballs
In light of the recent supply chain attack in xz/lzma, leading to a backdoor in openSSH (https://www.openwall.com/lists/oss-security/2024/03/29/4), I believe that it would be a good idea to remove the huge attack surface offered by the pre-generated autoconf build scripts and lexers, offered in the release tarballs. In particular, the xz supply chain attack injected the exploit with a few obfuscated lines, manually added to the end of the pre-generated configure script, that was only bundled in the tarballs. Even if the exploits themselves were committed to the repo in the form of test files, the code that actually injected the exploit in the library was not committed to the repo, and was only present in the pre-generated configure script in the tarball: this injection mode makes sense, as extra files in the tarball not present in the git repo would raise suspicions, but machine-generated configure scripts containing hundreds of thousands of lines of code not present in the upstream VCS are the norm, and are usually not checked before execution. Specifically in the case of PHP, along from the configure script, the tarball also bundles generated lexer files which contain actual C code, which is an additional attack vector, i.e. here's the diff between the tarball of the 8.3.4 release, and the PHP-8.3.4 tag on the git repo: ``` ~ $ diff -r php-8.3.4 php-src -q Only in php-src: .git Files php-8.3.4/NEWS and php-src/NEWS differ Files php-8.3.4/Zend/zend.h and php-src/Zend/zend.h differ Only in php-8.3.4/Zend: zend_ini_parser.c Only in php-8.3.4/Zend: zend_ini_parser.h Only in php-8.3.4/Zend: zend_ini_parser.output Only in php-8.3.4/Zend: zend_ini_scanner.c Only in php-8.3.4/Zend: zend_ini_scanner_defs.h Only in php-8.3.4/Zend: zend_language_parser.c Only in php-8.3.4/Zend: zend_language_parser.h Only in php-8.3.4/Zend: zend_language_parser.output Only in php-8.3.4/Zend: zend_language_scanner.c Only in php-8.3.4/Zend: zend_language_scanner_defs.h Only in php-8.3.4: configure Files php-8.3.4/configure.ac and php-src/configure.ac differ Only in php-8.3.4/ext/json: json_parser.tab.c Only in php-8.3.4/ext/json: json_parser.tab.h Only in php-8.3.4/ext/json: json_scanner.c Only in php-8.3.4/ext/json: php_json_scanner_defs.h Only in php-8.3.4/ext/pdo: pdo_sql_parser.c Only in php-8.3.4/ext/phar: phar_path_check.c Only in php-8.3.4/ext/standard: url_scanner_ex.c Only in php-8.3.4/ext/standard: var_unserializer.c Only in php-8.3.4/main: php_config.h.in Files php-8.3.4/main/php_version.h and php-src/main/php_version.h differ Only in php-8.3.4/pear: install-pear-nozlib.phar Only in php-8.3.4/sapi/phpdbg: phpdbg_lexer.c Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.c Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.h Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.output ``` To prevent attacks from malevolent/compromised RMs, I propose completely removing all autogenerated files from the release tarballs, and ensuring their content exactly matches the content of the associated git tag (this means also removing the -dev prefix from the version number in main/php_version.h, Zend/zend.h, configure.ac and NEWS in the git tag). Of course this means that users will have to generate the build scripts when compiling PHP, as when installing PHP from the VCS repo. I'm sending a copy of this email to secur...@php.net as well.
Re: [PHP-DEV] [RFC] Release cycle update, take #2
>> I would like to propose a new process RFC for updates to PHP release >> cycle: >> >> https://wiki.php.net/rfc/release_cycle_update I would also like to propose an addition, allowing patch releases to be made outside of the normal release schedule if a major core feature is broken by a fix in the previous patch release. These out-of-schedule releases should only contain a clean revert of the fix that broke the major core feature. I believe the "major core feature" set should include at least the garbage collector and string functions, it may be extended if needed. I'm advocating for this change due to the fact that critical garbage collector bugs were introduced and released at least twice in the last year: - First with a GC patch that completely broke garbage collection causing segfaults if fibers are used (https://github.com/php/php-src/pull/9810) - And then with a GC patch that broke garbage collection causing segfaults when using weakmaps (https://github.com/php/php-src/pull/10932) Specifically regarding the first bug, the fix for it was actually delayed by 30 days, instead of 15 (the time left until the next release, when the fix PR was merged), as a security release was made the day after the fix was merged, delaying the entire release cycle by 30 days. I believe that bugs in major core features, introduced by fix PRs should be reverted ASAP, especially if they aren't noticed until a release, instead of breaking a core feature of the language for one month (or more if a security release delays the normal release cycle). Also in general, I find it wrong that security releases should delay the normal cycle. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
> The VSC part from github (hosting our code), can very easily be ported. > Issues, discussions etc can not. > > With the ongoing enshittification of most of the Internet due to advertising > and tracking, we'd be negligent not hosting and owning our own content > (including our issue tracker, but that ship has sailed now). PHP actually recently moved from a self-hosted VCS to github due to a hack that compromised php's source code, moving back to a self-hosted instance seems like a downgrade. However, if that's being discussed, it can be done properly, i.e. with a self-hosted gitlab instance, which also provides issues, projects, CI, basically the full devops experience, that would be the perfect chance to also move the mailing list and php wiki to gitlab (which is how many FOSS projects work currently, I.e. wayland, xorg, mesa, pipewire, asahi use the gitlab.freedesktop.org gitlab instance, arch linux has its own gitlab instance (which is also used for RFCs)). > Email has been around for half a century. Will things like Slack, Discord, > and the like still be operational and allow access to our archives in another > 25 years? I'm almost certain it won't be. No one is proposing to move the issue tracker to discord, slack or telegram: those are messengers, and should not be used as support forums for such a major language, mainly because they're non-indexable. Regards, Daniil Gentili
Re: [PHP-DEV] is this thing on?
> Has Microsoft made a commitment to support open source forever? I mean MS > owns Github, what ensures that it will stay free? This is a silly argument, if that were the case, maybe the VCS should move back to a self-hosted instance too? Jokes aside, if Microsoft suddenly decides to throw away or to charge for github, one of their biggest assets after Windows and OpenAI, PHP would have bigger problems than RFCs being managed on the github issue tracker. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
>> Mailing lists are fine and PHP is not the only project using them. The >> Linux kernel successfully uses them, the HAProxy project does as well >> and so does Debian. >> >> Best regards >> Tim Düsterhus > > Hi, Internals > > There are times when I explore archives (mbstring and character code > etc), so it's helpful to have something left in communication form. > Therefore a mailing list would be better for that. Modern programming languages like Rust and Go use exclusively github for internals discussion and RFCs, and all conversations are easily accessible, searchable and indexed by Google, with a much better UX than mailing lists. Just my two cents, I still believe using mailing lists and an invite-only wiki adds needless friction. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
And no, I don't like discussion forums like reddit or Discord either. Discord should be completely out of question, given that it is non-indexable by search engines (btw, technically this mailing list isn't indexable either without projects like externals.io). Writing to the amount of people following php internals should be done with some consideration and more social media type of platforms unfortunately - in my experience - tend to encourage noise. As I mentioned in my other reply in this thread, IMO sending an email is not a gigantic barrier to entry, as can be seen by the often low (technical and overall) quality of the replies to many of the threads on this list. Personally, I do not think that gatekeeping (!) and spam-prevention are a good reason to keep using a broken and outdated system like mailing lists in 2024. Large projects like PHP will still inevitably attract attention, regardless of whether github or mailing lists are used; I personally dislike mailing lists not because they are difficult to use, but because they are simply broken: every time I had to deal with any mailing list, including this one, I had both incoming and outgoing deliverability issues related either to DKIM/DMARC, both on gmaill and zoho mail on a custom domain, or some other issue caused by modern anti-spam measures that mailing lists do not account for. I really don't think that a modern discussion system can afford to randomly loose messages: mailing lists should not be used in 2024. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
This has also come up in the past regarding moving from e-mail to $currently_fashionable_technology - having some barrier to entry is actually quite useful, since we want people to put some effort into their contributions beyond "me too" or "I had this crazy idea in the pub". IMO sending an email is not a gigantic barrier to entry, as can be seen by the often low (technical and overall) quality of the replies to many of the threads on this list. Personally, I do not think that gatekeeping (!) and spam-prevention are a good reason to keep using a broken and outdated system like mailing lists in 2024. Large projects like PHP will still inevitably attract attention, regardless of whether github or mailing lists are used; I personally dislike mailing lists not because they are difficult to use, but because they are simply broken: every time I had to deal with any mailing list, including this one, I had both incoming and outgoing deliverability issues related either to DKIM/DMARC, or some other issue caused by modern anti-spam measures that mailing lists do not account for. I really don't think that a modern discussion system can afford to randomly loose messages: mailing lists should not be used in 2024. Regards, Daniil Gentili.
Re: [PHP-DEV] is this thing on?
gmail is failing to send emails to the list (hence why it has probably been a bit quite around here). Here is the error: +1, personally I would just switch to github issues and discussions, even ignoring all the deliverability issues, I don't think using a mailing list is a good idea for a modern programming language, seeking new contributors and new ideas in 2024. VCS was already moved to github after the recent hack of the php VCS, a lot of technical internals-related discussion is already using exclusively github issues and pull request discussions, I believe that the mailing list is nothing more than a redundant relic of the past. Regards, Daniil Gentili
Re: [PHP-DEV] What's up with emails?
> If I'm using gmail and not getting emails, how many other people are > also not getting emails on this list? > Same here, with both gmail and zoho mail. Personally I would switch to github issues and discussions, even ignoring all the deliverability issues which I had even before the switch to the new mailing list server on my zoho mail dan...@daniil.it account, I don't think using a mailing list is a good idea for a modern programming language, seeking new contributors and new ideas in 2024. VCS was already moved to github after the recent hack of the php VCS, a lot of technical internals-related discussion is already using exclusively github issues and pull request discussions, I believe that the mailing list is nothing more than a redundant relic of the past. Regards, Daniil Gentili
[PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes
Hi all, I've opened voting for the final-by-default anonymous classes RFC: https://wiki.php.net/rfc/final_by_default_anonymous_classes Regards, Daniil Gentili.
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
Hi, > But holding up the entire conversation because these things don't even > exist, BTW, I'm not asking to wait for the implementation of a native event loop before implementing a worker mode, I'm asking to design the worker mode API in a way that is compatible with an eventual native event loop (that I hope will eventually get merged into php, as the current status quo of blocking STL I/O is definitely not ideal for a programming language in 2024). Using superglobals for request information is already using a wrong approach in sight of native async, and while technically this is not completely incompatible with fibers, as superglobals can simply be copied immediately as soon a fiber is started, the same cannot be said for php://output and php://input streams, which cannot be copied in any way. I ask to completely avoid altering superglobals and other global state such as the php://input/output streams, and instead directly pass/return an array/object (it really does not matter to me if it's a PSR-7 RequestInterface or an array containing _GET, _POST, input, output keys, or anything else as long as superglobals and global state is not touched in any way). Backwards compatibility for code using superglobals is really a non-issue here, as worker mode in itself is already potentially NOT automatically backwards-compatible with legacy code, since applications running in worler mode have to deal with the fact that the global state is not reset at the end of each request. This in itself is not an issue as mentioned before, thanks to work inside of major PHP frameworks to better support worker mode, I.e. laravel octane, but since the beneficiaries of worker mode will mostly be modern frameworks and most legacy code will already require changes to better support it, using a new API with a standalone request object/array instead of superglobals is not a real issue. Regards, Daniil Gentili.
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
Hi, I've been lurking around in the discussion for a while, and I'd like to chime in now since the main, glaring issue with this proposal has only been explicitly mentioned by Rowan Tomminis, with that subthread quickly degenerating with misguided replies. PHP as a language absolutely needs a persistent worker mode like in all other backend languages, which will greatly improve performance by avoiding all overhead related to request initialization. However, the current proposal of adding support for worker mode SAPIs based on the usual PHP superglobals is fundamentally incompatible with concurrency (aka async, aka swoole, amphp, fiber-based concurrent runtimes in general), and I believe would steer the PHP ecosystem in the wrong direction. Rowan already offered a nice example of why earlier in the thread, but as an explanation to those that may not have understood that, so I whipped up a briefer at https://gist.github.com/danog/f0e9103e6a7e1bcec1b92c411a3c4607 So no, unlike what I've read in another message here, "The nodejs curse [...] where async and co may actually slow down your whole node." is simply false for the majority of modern usecases, because the majority of modern applications is I/O-intensive, not CPU-intensive. Implementing a worker API the way it is proposed is fundamentally incompatible with userland cooperative schedulers aka event loops like amphp or reactphp, and each request would be handled, just like in php-fpm, in a separate OS thread, not in a much more efficient userland thread. Cooperative schedulers implemented outside of PHP in the form of an extension such as swoole would also not be able to easily make use of the initially proposed API to handle requests in separate coroutines, even if the handle_request function was intercepted by swoole to return control to the swoole event loop (which would already make it superfluous as a PHP API), since the proposal involves messing around with the usual superglobals, which as mentioned by Rowan would require manual copying of the superglobals before using them in a newly spawned swoole coroutine. I believe that a much, much better way of implementing a worker mode in PHP core would be to provide a fiber-aware function/static method returning, upon receiving a request, a class implementing the PSR-7 RequestInterface. Fiber-aware here means that the function should behave in a way similar to how all native PHP I/O functions should behave in an upcoming Native Event Loop RFC I'm planning to make. The idea here is to make all I/O related functions, including this new wait_request function, completely async in a manner that is compatible with fibers and pure PHP event loops like amphp. It would essentially work as follows: an event loop like uv is integrated within PHP itself at least for the native stream wrapper (I.e. all filesystem and network functions, file_get_contents and so on). Extensions will be provided an API to interact with the event loop. I'm currently finalizing the details, and might probably make a first RFC in the coming weeks, suffice to say that everything will work in a manner very similar to how async works in both the ext-pq and php-tokio extensions, albeit with fiber integration: a separate event loop (let's call it native) is started in another OS thread (like with ext-pq or php-tokio, WITHOUT the need for ZTS, as no PHP data structures are modified in the native event loop), events are sent via a single descriptor from the native event loop to the userland event loop (I.e. amphp). If running inside a fiber, tasks are queued to the native event loop and the fiber is suspended with a NativeSuspension, then resumed by the userland event loop. If not running inside a fiber, tasks are queued to the native event loop and control is returned to the userland event loop. Essentially, my proposal is almost exactly what is already being done in https://github.com/danog/php-tokio, but library-agonstic and implemented inside of PHP itself, perhaps even using Rust and tokio as well. I feel that the current direction of the discussion of PHP worker modes is wrong, as it is mostly ignoring the presence of a perfectly usable concurrency API in PHP (fibers): this has potential to cause a big split in the PHP ecosystem, unless PHP finally fully embraces concurrency and async with a native event loop proposal, like the one I intend to present soon. I hope that further discussion of a worker mode continues with an eye to the future with native concurrency :) Regards, Daniil Gentili. P. S. Just in case to avoid confusion for some, frankenphp does NOT add native concurrency to php using goroutines, as control to the go event loop is only returned when calling functions like header or echo which cause a suspension of the goroutine because an I/O operation is made on the go side, but 1) That's incompatible with fibers, and not just because of th
[PHP-DEV] [RFC] [Discussion] Final by default anonymous classes
Hi, After the feedback received in the final voting thread for the final anonymous classes RFC, I've created another RFC this time to make anonymous classes final by default, here it is: https://wiki.php.net/rfc/final_by_default_anonymous_classes Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] [RFC] Final anonymous classes
Hi all, Thanks for the feedback, sorry the RFC was a bit too thin, given the multiple internals threads I started on the topic, including the latest [RFC] discussion thread, I mistakenly assumed that everyone was already familiar with the topic, even if by just lurking. To reply to some of the feedback received in this thread, >I am especially missing a reasoning as to why final for anonymous classes is a thing in the first place. What pain is this RFC adressing? The only real pain I was addressing was indeed the inability to enable some possible opcache optimizations when using final classes, as mentioned in the Proposal section; I believe that that is reason enough to add support for a minor feature like this. >There is no reasoning, or examples Added some more reasoning, even though as said both here and the RFC, the reason behind the RFC is quite simple, just allow using some optimizations that were excluded due to an oversight in the original implementation of anonymous classes. Regarding the examples I again mistakenly assumed that everyone was already familiar with the (rather basic) patch and the examples in the testsuite, corrected that mistake now. Regarding the voting options, after feedback received in the last [RFC] discussion thread from Nicolas Grekas: >Hi Daniil, >>> While I'm open to Proposal 1, which introduces final anonymous classes >>> without breaking BC, Proposals 2 and 3 are a different story. >>> In summary, I advocate for the RFC to focus on the non-BC-breaking option. >>> Let's maintain our commitment to stability and gradual evolution in PHP. >>> Cheers, >>> Nicolas >> Agree with your points, just adding final anonymous classes seems the best solution to me, but given the interest in alternative solutions both in the pull request discussion, and in the previous mailing list thread, I think I'll leave the other options in the RFC, to see how the votes will go (I'm actually curious myself :). >> Regards, > Daniil Gentili >I think this is a dangerous game. Breaking BC shouldn't be proposed unless absolutely needed IMHO. >Nicolas I had moved a large chunk of the rationale and removed basically all the alternative polls I had initially planned to propose; the initial text of the RFC can be seen at the bottom, in the newly updated Rejected Features section (https://wiki.php.net/rfc/final_anonymous_classes). I've also added some additional pro and counterpoints on my own. As I see now, it was a mistake to remove the other two planned voting options just based on a single feedback, thus I would like to ask, would it be OK to add back the two voting options I removed basically a day before opening voting, with end date @ 2023-12-20? Here are the options I removed a few days ago, and would like to add back: - Make all anonymous classes final by default, without the option to make them final? - Yes/No - Make all anonymous classes final by default, provide an optional ''open'' keyword to make them non-final - Yes/No Again to clarify, the voting options would be mutually exclusive as proposed in the original version of the RFC. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Hi Nikita, For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a class_alias loophole that could, in theory, have been used to extend anonymous classes in the past. Especially given that there is no evidence of this "feature" being used in the wild (or if there is such evidence, it was not presented in the proposal). Should I amend the RFC, recreating the current poll with three mutually exclusive options (final anonymous classes, final by default without open, final by default with open) instead of just Yes/No (I personally share your PoV, but given the minor pushback received in the last discussion thread I initially decided against it), could that be done without restarting the discussion process? Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] [RFC] Change how JIT is disabled by default
Hi all, I've just opened voting for the "Change how JIT is disabled by default" RFC @ https://wiki.php.net/rfc/jit_config_defaults. Voting started now, and will run until December 18th 2023, 00:00 GMT. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] [RFC] Final anonymous classes
Hi all, I've just opened voting for the final anonymous classes RFC @ https://wiki.php.net/rfc/final_anonymous_classes. Voting started now, and will run until December 18th 2023, 00:00 GMT. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes
Hi, Pick an approach and put that up for a vote, Picked the basic option of just adding final anonymous classes & edited the RFC accordingly. Thanks for the feedback! Regards, Daniil Gentili.
Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes
Hi all, Heads up, I'll move this RFC (https://wiki.php.net/rfc/final_anonymous_classes) to voting status tomorrow! Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default
Hi all, Heads up, I'll move this RFC (https://wiki.php.net/rfc/jit_config_defaults) to voting status tomorrow! Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Is it possible to add asynchronous loop call function ?
Hi, Thinking about it some more, I think we can go even further than that and actually implement defer (enjoying the code golf)! Dropping this here, just in case :) https://github.com/php-defer/php-defer From the posts on this thread (and the star count on php-defer), it seems there is indeed some interest in a defer keyword for PHP, might actually get to writing an RFC implementing the keyword itself this weekend... Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: 回复: [PHP-DEV] Is it possible to add asynchronous loop call function ?
Hi, > it is not golang's defer, they is similar javascript async call function of > working mode. For that, you can easily async libraries like amphp/revolt (https://amphp.org), which use fibers (as PHP fibers were created mainly for amphp/revolt, by the developer of amphp/revolt). You probably want to use the EventLoop::delay function (https://revolt.run/timers), or the async function (https://amphp.org/amp#coroutines). Regards, Daniil Gentili.
Re: [PHP-DEV] Is it possible to add asynchronous loop call function ?
Hi, You probably want something similar to golang's defer keyword. I intend to submit an RFC and PR for a defer keyword in PHP sometime in the future. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - static modifier for classes
Hi again, > Super on board with this Sorry for top posting everyone, my bad, forgot to delete the rest of the message :) Regards, Daniil Gentili
Re: [PHP-DEV] RFC Proposal - static modifier for classes
19 nov 2023 22:28:16 Lanre Waju :
> Hi, similar to the abstract and readonly modifiers to classes (similar in
> syntax only), I propose a class level "static" modifier that ensures:
>
> 1. The class cannot be instantiated and will throw an exception if attempted.
>
> 2. All methods and variables in the class are implicitly static.
>
> 3. (optional based on community input) It should have the same effect on
> traits and interfaces
>
> For example:
>
> static class X {
>
> const int k = 1;
>
> private string $a
>
> function foo():void{}
>
> private function bar():void{}
>
> }
>
> would be equivalent to
>
> class X {
>
> const int k = 1;
>
> private static string $a
>
> public static function foo():void{}
>
> private static function bar():void{}
>
> }
>
> and so on. I will be implementing this myself it it gets approved.
>
> Cheers,
>
> Lanre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
Hi,
Super on board with this, I felt the need for this feature uncountable times in
many years, usually the temporary solution was just to mark the class as final
and create a private constructor, but especially the private constructor part
makes it a bit ugly, too indirect and not immediately obvious.
The only doubts I have about this proposal are the omission of static keywords
for functions and properties.
I understand this is inline with readonly classes, but I don't feel like static
is a keyword that should be omittable when declaring static methods and
properties.
Regards,
Daniil Gentili.
Re: [PHP-DEV] [RFC] [Discussion] Final anonymous classes
Hi, > While I'm open to Proposal 1, which introduces final anonymous classes > without breaking BC, Proposals 2 and 3 are a different story. > In summary, I advocate for the RFC to focus on the non-BC-breaking option. > Let's maintain our commitment to stability and gradual evolution in PHP. Agree with your points, just adding final anonymous classes seems the best solution to me, but given the interest in alternative solutions both in the pull request discussion, and in the previous mailing list thread, I think I'll leave the other options in the RFC, to see how the votes will go (I'm actually curious myself :). Regards, Daniil Gentili.
Re: [PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default
16 nov 2023 10:28:16 Dmitry Stogov : >> No problem, I can change the defaults but remove the fatal error if >> jit=non-zero and jit_buffer_size=0, can I still turn it into a warning >> though? >> > > I think we don't need the warning. It's clear that JIT won't work with > "opcache.jit_buffer_size=0" in php.ini. > > Thanks. Dmitry. Hi, All done, updated both RFC and pull request :) Regards, Daniil Gentili
[PHP-DEV] Report fatal error if JIT cannot be enabled due to a misconfiguration
Hi all, Just a heads up as asked by Ilya, regarding https://github.com/php/php-src/pull/12403: this PR will improve the JIT startup logic by actually emitting a fatal error preventing PHP startup in case of a misconfiguration or other JIT-related issues. The fatal errors will explain the exact reason why JIT startup failed, obviously if and only if JIT is explicitly enabled in the configuration (which it isn't, by default). I feel this is a distinct improvement over the current implementation which just silently disables JIT, with no logs whatsoever, to the point where the only way of finding out that JIT is not enabled even if you did enable it in the config is running opcache_get_status. Hope it's all fine by you, planning to get this merged by PHP 8.4. Regards, Daniil Gentili.
Re: [PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default
Hi Dmitry, After upgrading to the new PHP version with this patch, all of them won't be able to start PHP. I don't care a lot about the php.ini defaults, but I don't like to give our users a headache. No problem, I can change the defaults but remove the fatal error if jit=non-zero and jit_buffer_size=0, can I still turn it into a warning though? Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Final anonymous classes
Hi, Regarding the RFC itself, I find the voting options unclear. It says that they are mutually exclusive, but it doesn't say what happens when multiple are accepted. Personally I can see myself voting for both "Option 1" and "Option 2", because I believe it is useful if users would be able to make them final for consistency, but I would find it even more useful if they would all be final by default, but would not find it useful to introduce a new 'open' keyword. Some other folks might want to see all anon classes final by default, but don't care about whether there is the escape hatch or not and thus would vote for all 3 options. Thanks for all the tips, did everything (I did indeed forget to add the rfc to the main page, thanks for reminding me!). Regarding the voting options, all three options are mutually exclusive, but since some people (myself included) may be OK with more than one of the following options and may vote in favor of more than one option, I would propose a tie-breaker second vote in case more than one of the options finish with the same number of favorable votes. In this second, eventual tie-breaker vote, voting favorably for only one of the options would be allowed. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [Discussion] Final anonymous classes
Hi all, I would like to submit an RFC and PR to add support for final anonymous classes, /or/ make all anonymous classes final by default, with or without the possibility to make them non-final. Here's the URL of the RFC: https://wiki.php.net/rfc/final_anonymous_classes I'd more more than glad to receive some feedback! Regards, Daniil Gentili.
[PHP-DEV] [RFC] [Discussion] Change how JIT is disabled by default
Hi all, I would like to submit an RFC and PR to change a few INI defaults for opcache, changing how JIT is disabled by default. Here's the URL of the RFC: https://wiki.php.net/rfc/jit_config_defaults. I'd more more than glad to receive some feedback! Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Final anonymous classes
Hi all, I've created the RFC, I'd be more than glad to receive feedback: https://wiki.php.net/rfc/final_anonymous_classes Thanks, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Change default method of disabling JIT for PHP 8.4
Hi all, I've created the actual RFC: https://wiki.php.net/rfc/jit_config_defaults Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Previous discussions about generics syntax only?
Hi, > There are still a lot of people who use a cheap shared host, edit a file > directly on the live environment, and expect it to just work without needing > any kind of rebuild or restart step. Nothing will change in that sense, the only difference is the addition of compile-time autoloading and type checking. No preloading (in the sense of no opcache configuration needed), nothing special. > If you use the JIT in advance, it becomes a very different tool - the point > of JIT compilation is to make use of runtime information about hot paths, the > actual types of dynamic arguments, etc Not with function JIT, function JIT is the closest thing we currently have to an AOT compiler in php (minus the actual executable generation, since it all happens in memory), it just compiles opcodes without any optimizations based on runtime type information (unlike tracing JIT, which does use runtime type information). Regards, Daniil Gentili.
Re: [PHP-DEV] Deprecate posix_times
Hi, > It is exposed: > https://github.com/php/php-src/blob/66e2aa725564c2221ace7a26628afe3957f28237/ext/posix/posix.c#L1232-L1241 > Welp completely missed that, my bad, it was added in php 8.3, that's why I couldn't find it in the docs :) Respectfully, I will still be editing the deprecations RFC anyway to see if the voting passes. Kind regards, Daniil Gentili.
Re: [PHP-DEV] Previous discussions about generics syntax only?
Hi, > Doesn't that just take us back to the "generic types are only optionally > checked" scenario you were trying to avoid? Of course, my idea would also require bundling and enabling opcache by default with PHP and actually requiring the preloading+compilation step in order to run any code, like for any other statically typed compiled language. I.e. no more REPL-like, open world assumptions: all referenced classes and types must be present (or autoloadable) at compile time, with no way provided to disable compile-time type checks, like for any statically typed language (of course this would be somewhat of a breaking change, PHP 9-worthy). > you've got to switch from rules for loading classes at runtime to generating > a static preload list in advance. > To be reliable for static analysis, that preload list would need to be > *comprehensive*, defining every symbol up front, then making a second pass of > cross-file analysis. The preload list does not have to be generated manually, PHP itself could autonomously autoload all required classes at compile time (this differs from the current behavior, where autoloading is only triggered during execution of code mentioning not-yet-loaded classes). >That makes it look very much like a separate build step, rather than something >integrated into the normal execution pipeline. Well yeah, but it doesn't have to be separate from the execution step, I.e. I don't see why running a script using php a.php should not be able to autoload all reachable classes during compile time instead of at runtime, I.e. because they're mentioned in typehints, not because the function using the typehint is being executed. >I've said before that this might be the way PHP should go - a native "module" >concept, with full pre-compilation - but it would be quite a radical change. This is a different, unrelated matter, and it would actually be super cool to generate a single executable using function JIT, bundling both the compiled php code and php itself; I've actually already done this as an experiment with another JIT language based on dynasm, it's quite simple really. > Perhaps an alternative is to change the rules of when autoloading can be > invoked, by allowing the preload script to recursively autoload every symbol > it can identify, rather than waiting for the relevant code to be executed. I > think this is how current offline static analysers work. Precisely. > That doesn't solve the "optional checks" problem, though, if preloading > remains optional. We could produce an error if any generic/extended type was > encountered without being preloaded, but that poses a dilemma for libraries: > either don't use the new types, or impose a requirement for applications to > use preloading. I'm not convinced there's an easy compromise here. No need to preload, just autoload at compile time like you said, and polyfill missing classes that cannot be autoloaded. Regards, Daniil Gentili.
Re: [PHP-DEV] Previous discussions about generics syntax only?
Hi Ilija, The optimizer, including type inference, is limited to the scope of the current file (along with internal functions/classes). [...] Preloading is the exception, where all preloaded files can assume not to be changed after PHP has booted. Well, I was actually thinking of enabling these compile-time checks only if preloading is enabled, to ensure the closed-world guarantee. We could make type checking a CLI step but how is that really better than PHPStan or Psalm at that point Yeah don't really like the idea of a separate "typechecking" step either, I'd really love for this to be an integral part of the execution process, not as a separate static analysis step. PHPStan and Psalm are arguably successful *because* they are written in PHP, making them much easier to maintain and contribute to. Agreed, however if at least some static analysis functionality is already implemented, I see no reason to not make use of it, even if PHP does not accurately represent arrays in the optimizer and has no notion of array shapes. personally I really like array shapes but *only* as a stopgap measure while switching to full object DTOs, so I'm comfortable with the idea of not having static analysis for array shapes (actually, I would absolutely love to just treat all array values as mixed during static analysis, though array/list generics might be nice and easy to implement...). Another issue, specifically pertaining to generics, is that PHP has type coercion. In both weak and strict typing mode, a float function parameter will coerce an integer value. However, if generic types are erased at runtime then the VM cannot do coercion for foo($int) (where function foo(T $var)). This will require either accepting inaccurate runtime types, or establishing stricter static rules that do not match the existing behavior. Well I'm all for stricter rules :) Regards, Daniil Gentili.
Re: [PHP-DEV] Final anonymous classes
Hi, > One thing I'm not sure about: What opcache optimizations would final enable? Well for example, any JIT logic gated behind a check on ZEND_ACC_FINAL: https://github.com/php/php-src/blob/master/ext/opcache/jit/zend_jit_trace.c#L4507 Regards, Daniil Gentili
Re: [PHP-DEV] Deprecate posix_times
Hi, > This deprecation appears to be sufficiently simple that it can likely be > included in the bulk deprecation RFC for PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 That would be super nice, who should I ping before editing the page? Regards, Daniil Gentili
Re: [PHP-DEV] Deprecate posix_times
Hi, I would like to echo the sentiment expressed by Tim earlier in another subthread: >If a function cannot be safely or correctly used at all, then it shouldn't >exist, especially if there are working alternatives [1]. > >Expecting users to find a warning in the docs to learn that they should >"never" use a function is not good developer experience. I am aware that the function is defined by the POSIX standard but 1) Not all POSIX functions are currently exposed by the POSIX extension, sysconf being one of the missing ones (with IMO no good reason to add it) 2) I am not aware of the historical reasons that lead to the addition of a duplicated, less capable function to the POSIX standard (I'm super duper sure there's some reason related to an implementation detail of some 30+ year-old platform :), but PHP isn't a POSIX-compliant OS, it is not PHP's task to expose the entirety of the POSIX standard functions: PHP's task is to provide a simple to use language that also exposes some *useful* functions from the POSIX standard, and posix_times does not fit the definition, in my opinion. Regards, Daniil Gentili.
Re: [PHP-DEV] Previous discussions about generics syntax only?
Hi all, Perhaps chiming into the conversation a bit too late, but I would personally like to say that I *really* do not like the idea of attribute-like, unvalidated generics syntax. As a maintainer of Psalm and an active user of it both personally and at work, I absolutely *adore* the typesafety and ergonomics generics can provide, but all benefits are nullified if generics are not not actually typechecked. Generics can be typechecked by: - The language itself, which *requires* all types to be correct - Oe by a static analysis tool which is specifically added to a given project for the purpose of typechecking generics: in this case, we can consider to be using a superset of PHP which similarly *requires* the static analysis to pass in order to "compile" the source code (I.e. if the Psalm pipelines are red, deployment is blocked). Generics whose syntax is fully provided by the language, but then can only be *optionally* typechecked by installing third party unofficial tools are not, in my opinion, an improvement over the status quo. Now, after reading this thread I was actually inspired to implement runtime typechecked generics in PHP itself, and https://github.com/nicelocal/php-src/tree/generics is the single-evening result of that: it features generics support in the parser, and some initial, partially committed runtime validation. However, I paused the effort for the reasons listed in https://github.com/php/php-src/pull/8752: runtime generics typechecks are (needlessly) expensive. The much better approach, one that I intend to maybe give a shot at this Christmas, is to add static analysis functionality to PHP itself (i.e. turn it into a truly statically typed language). I have a hunch it may be easy enough to do by hooking into the type inference functionality provided by opcache, and throw compile-time exceptions instead of silently inserting runtime typechecks. This functionality may be initially enabled through a declare(static_types=1); statement, and might actually also help find bugs in the type inference functionality which causes JIT bugs. Personally I'm super excited for the possibility of introducing static typechecking in PHP itself, partially because it also allows to easily and cheaply implement generics. Regards, Daniil Gentili
Re: [PHP-DEV] Short Function Syntax
Hi,
I don't hate the idea, I actually really like the rust-ish look of it, though
personally I would prefer to have short function syntax for closures before
methods (I.e. fn () { ... } is a syntax I wanted and could not use countless
times in all the years since the introduction of arrow functions...)
Regards,
Daniil Gentili.
Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4
Hi, This is precisely why I'm planning to submit the RFC to make the change in PHP 8.4, which is when the new JIT will be introduced. Regards, Daniil. On 10/18/23 08:52, Christian Schneider wrote: Am 17.10.2023 um 19:46 schrieb Daniil Gentili : I would like to submit an RFC and PR to change a few INI defaults for opcache, changing how JIT is disabled by default. Currently, JIT is disabled by default using the |opcache.jit_buffer_size=0| default, instead of |opcache.jit=0|. I would like to change these defaults to: - opcache.jit=off - opcache.jit_buffer_size=64m (taken from https://github.com/php/php-src/pull/12425/files, any smaller multiple of 2 causes the buffer to fill up when running moderately sized projects like Psalm or PHPStan). I understand your point but it might unexpectedly switch behavior for people just setting jit_buffer_size and expecting this to turn JIT on. While (in the light of a new upcoming JIT) this might not be a big deal it is also not clear if it is worth it. Maybe the settings can be overhauled once the new JIT is introduced (which might have different settings anyway). Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate posix_times
Hi, As listed in my original thread, I think that offering posix_times without offering sysconf would be like offering a version of the microtime function, which returns a value divided by a *undocumented and unexposed divider that changes in each patch version of PHP*. The main reason I would like to see this deprecated is not the fact that it's returning a less precise value compared to getrusage, but rather because it's returning a value that cannot be interpreted in any way from pure PHP. Regards, Daniil Gentili. On 10/18/23 09:00, Christian Schneider wrote: Am 17.10.2023 um 19:39 schrieb Daniil Gentili : I would like to submit an RFC (and related PR) to deprecate posix_times for PHP 8.4, removing it for PHP 9. My question here would be: Is there sufficient reason to remove this function and introduce a BC break, i.e. is the implementation code hard to maintain or does the function cause security issues? Unless that is the case I'd leave it unchanged and just add a note to the documentation that people might want to consider using getrusage() instead. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC Karma request
Hi, internals. I'd like to create RFCs at least for final anonymous classes (https://externals.io/message/121356) and a small tweak to JIT defaults (https://externals.io/message/121359). Please give me RFC Karma :) Username: danog Kind regards, Daniil Gentili. -- GitHub: https://github.com/danog -- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Change default method of disabling JIT for PHP 8.4
Hello, I would like to submit an RFC and PR to change a few INI defaults for opcache, changing how JIT is disabled by default. Currently, JIT is disabled by default using the |opcache.jit_buffer_size=0| default, instead of |opcache.jit=0|. I.e. here are the defaults for these two configuration entries: - opcache.jit=tracing - opcache.jit_buffer_size=0 This effectively disables JIT not because `jit=0`, but rather because the buffer size is set to 0. I would like to change these defaults to: - opcache.jit=off - opcache.jit_buffer_size=64m (taken from https://github.com/php/php-src/pull/12425/files, any smaller multiple of 2 causes the buffer to fill up when running moderately sized projects like Psalm or PHPStan). What do you think? Kind regards, Daniil Gentili.
[PHP-DEV] Deprecate posix_times
Hi everyone,
I would like to submit an RFC (and related PR) to deprecate posix_times
for PHP 8.4, removing it for PHP 9.
There are multiple reasons to deprecate this function:
1)
The values which times(2) returns are expressed as the number of clock
ticks elapsed since the process was started: the frequency of the
aforementioned clock varies from platform to platform, and PHP does not
expose the sysconf(2) function, which is what should be used to fetch
the clock frequency, invoking `sysconf(_SC_CLK_TCK)`.
Thus, users have to deal with time values which **cannot be portably
converted to microseconds**: this has actually bitten us @ work, where I
recently found an ancient piece of code which incorrectly hardcoded the
(undocumented) clock frequency of 100hz used on (most) Linux platforms:
running the code on a Linux platform like ia64 [1], or any other POSIX
OS which uses a different clock frequency would have silently reported
an incorrect value, with no way to obtain the correct clock frequency
from PHP.
2)
Equivalent functionality is already provided by getrusage(), with a
*much higher resolution*:
*a.php:*
'utime_times' => $stat['utime'] * 10_000, // Assuming 100 hertz
clock on x86 linux
'stime_times' => $stat['stime'] * 10_000, // Assuming 100 hertz
clock on x86 linux
'utime_rusage' => $r['ru_utime.tv_usec'] + ($r['ru_utime.tv_sec'] *
1000_000),
'stime_rusage' => $r['ru_stime.tv_usec'] + ($r['ru_stime.tv_sec'] *
1000_000),
];
var_dump($res);
*Result:*
array(4) {
["utime_times"]=>
int(16)
["stime_times"]=>
int(0)
["utime_rusage"]=>
int(163672)
["stime_rusage"]=>
int(4994)
}
As you can see, with a system time of ~5 milliseconds, posix_times()
even returns 0, since the minimum duration that can be represented with
a 100 hertz clock (the default on most Linux platforms) is 10 milliseconds.
Waiting for feedback, kind regards,
Daniil Gentili.
[1]:
https://github.com/bminor/glibc/blob/69239bd7a216007692470aa9d5f3658024638742/sysdeps/unix/sysv/linux/ia64/getclktck.c
[PHP-DEV] Final anonymous classes
Hi everyone,
I'd like to submit an RFC to add support for final anonymous classes.
This should also allow some additional opcache optimizations.
I've already prepared the implementation at
https://github.com/php/php-src/pull/11126, what do you think?
Personally, I would have instead preferred the much cleaner approach of
making *all* anonymous classes final by default, (preferrably) without
offering the option to make them non-final.
However, I understand that this might be a little bit too restrictive
for something that may have some valid usecases, even if extending
anonymous classes currently requires some hack-ish workarounds with
class_alias.
All in all, as per the title, I'd just like to add support for final
anonymous classes (new final class {}), without changing any existing
semantics.
What do you think?
Thanks,
Daniil Gentili.
[PHP-DEV] Final anonymous classes
Hi all, I've submitted https://github.com/php/php-src/pull/11126 to add support for final anonymous classes, though as noted by iluuu1994, it would probably make more sense to just make all anonymous classes final by default, what do you think? Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
