Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository
> It should contain the consolidated unified policy documentation that is > "currently" active. > The other option is what we currently have, and I am proposing to go > away from. So the idea is that this repository is not a > collection of the accepted policy *amendments* (or *replacements*), > as that's what the RFCs / PRs are still for. Thank you for the explanation. That's exactly what I was hoping for. Kind regards, Jorg
[PHP-DEV] Re: [RFC] [Discussion] Improve callbacks in ext/dom and ext/xsl
Hi internals On 07/11/2023 20:32, Niels Dossche wrote: > Hi internals > > I'm opening the discussion for my RFC "Improve callbacks in ext/dom and > ext/xsl". > RFC link: https://wiki.php.net/rfc/improve_callbacks_dom_and_xsl > > Kind regards > Niels It's been almost 2 weeks since the last change to the RFC, and over a month since the discussion started. No discussion has happened in the last 2 weeks. I'd like to move this to voting on Thursday. Due to the holidays I will let the voting run for 3 weeks instead of 2. Please raise any final remarks or complaints now. Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] FFI in PHAR files
> If you choose not to use a phar, but instead, just loose PHP files, it > extracts the sources to a random `/tmp` directory when executing. So, > FFI and other things should "just work" without any shenanigans. > > Robert Landers > Software Engineer > Utrecht NL Thank you for the suggestion. The micro.sfx SAPI doesn't support adding multiple files, afaik, so what you mean is concating micro.sfx to my "entrypoint" and providing the whole source instead of just an executable? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Collecting All Policies Into One Repository
On Mon, 18 Dec 2023, Jorg Sowa wrote: > I have one question regarding the future changes. Do you see it would > be possible to make amendment to the accepted RFCs by the Pull > Requests (and formal RFC approach) making changes the existing > policies or adding the new policy replacing the old ones? In other > words, this repository would server as the collection of all ever > accepted policies or it would contain the unified policy > documentation? It should contain the consolidated unified policy documentation that is "currently" active. The other option is what we currently have, and I am proposing to go away from. So the idea is that this repository is not a collection of the accepted policy *amendments* (or *replacements*), as that's what the RFCs / PRs are still for. > I'm asking because I saw the directory `archive`, and it contains > expired RFC. I don't think this would help new contributors. For the > history purposes it would be nice to have it in the git history, but > for the PHP development process is not relevant anymore and is little > overhead. I didn't really know what to do with these documents in archive, as they were sortof related to the release process/timeline document. I suppose we don't need them, but they are not *wrong* or *outdated*. Simply no longer needed as the time frame has passed. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] FFI in PHAR files
On Tue, Dec 19, 2023 at 3:35 AM Vinicius Dias wrote: > > > > I suppose it'd be possible to improve FFI to call the PHP VFS layer to > > > resolve a path, which would handle the phar:// scheme and other schemes. > > > But, I would be worried about potential other downstream impacts - esp. > > > security implications - as this is a novel (to me at least) scenario. > > I just realized I never explained the reason for me to wanna use this > feature. My bad. > > I have a CLI project that uses FFI and it would be awesome if I could > share it using the micro sfx API[1]. > > If FFI was supported inside PHARs, we could even create Desktop > applications using tools such as php-tkui[2] and make them available > via the aforementioned SAPI. > > Anyway, I just wanted to explain the motive behind my original question. :-D > > [1]: > https://github.com/crazywhalecc/static-php-cli/blob/main/README.md#use-micro > [2]: https://github.com/skoro/php-tkui > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Hello, > I have a CLI project that uses FFI and it would be awesome if I could > share it using the micro sfx API[1]. If you choose not to use a phar, but instead, just loose PHP files, it extracts the sources to a random `/tmp` directory when executing. So, FFI and other things should "just work" without any shenanigans. Robert Landers Software Engineer Utrecht NL -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
