[PHP-DEV] freopen() function
Hi there, I was checking our codebase and realised that we still use the function proposed by Antony a long time ago [1]. I run through the comments and feel like I can address the issues discussed back then. My question is what would be the best way to move forward? Shall I reopen the PR, create new or would it be better to start with a RFC? Links: [1] https://github.com/php/php-src/pull/950 [2] https://linux.die.net/man/3/freopen Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] path_join function
Hi, Thank you for the proposal - it echoes somewhere inside me. Just a little side-view of the problem... Personally, I will be a fan of Kotlin-style Path API E.g., the path is an object so we can get path items, and get sub-path/resolve child nodes. It appeared to be quite useful in practice. Examples: - https://stonesoupprogramming.com/2017/11/27/kotlin-path-interface/ - https://www.baeldung.com/kotlin/kotlin-path-api On Wed, May 17, 2023 at 4:36 PM Tim Düsterhus wrote: > > Hi > > On 5/17/23 16:54, p...@shyim.de wrote: > > When you concat just the paths you have to think about: > > - normalize string part to strip ending slash > > Why is it necessary to strip the ending slash? > > > - for windows compatibility you have to use DIRECTORY_SEPERATOR > > > > I don't use Windows, but to the best of my knowledge, using the '/' is > equivalent to the backslash. Is there a case where the difference matters? > > > I am really looking for your feedback, right now I have no “karma points” > > to create a RFC in the wiki :) > > > > If you want to proceed with an actual RFC, the folks handing out the RFC > karma would need your Wiki name. > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP internals to GitHub
Hello good people, Looks like another hot discussion on the list, isn't it? Just wanted to share my notice about the initial idea. 7 years ago there were people considering NNTP as an option. Nowadays, it's pretty clear that it isn't the way to go. It doesn't mean that technology is bad (although, someone can share their negative experience with that one) but instead, we hardly we can find a person who still uses it. If we switch to the News protocol, it is highly likely that we not just won't engage new members but instead, we'll lose those who are here. I reckon that this thread isn't about Github per se, it is rather a shout that the technology is declining. It happens slowly, hence it's hard to notice if you use it but suddenly you realise that people don't even know what a "mailing list" is. If we look at other projects (I will exclude Linux here: they still discuss patches over emails), many of them started using online tools (links below): * Firefox devs actively use Matrix (a free platform) as well as maillist * Kotlin doesn't use mail at all, they opted in using Slack + bug tracker + KEEPs (something like RFCs). * Docker does have a mailing list but it contains only spam over the last year PHP switched to Git and Github as the code repository, I believe for the same reason: it is a more popular and well-known tool these days. So, the tooling for me isn't the toy with new fancy features (personally, I'm happy with SVN and email: I'm an old codger), it's rather about engaging new people, and making their life simpler. Moreover, if we don't want to make a sharp move, we can try introducing a new tool and see the activity there (or even introduce this for other topics, like "PHP users", "Extension developers", etc...). Links: https://wiki.mozilla.org/Matrix https://github.com/JetBrains/kotlin/blob/master/docs/contributing.md https://groups.google.com/g/docker-dev Not trying to force any decision, just thought this was something that could be considered as well. Thanks and have a great day. On Wed, Apr 12, 2023 at 2:53 PM Alex Wells wrote: > > Hey. > > PHP currently uses internals@lists.php.net for communication. That includes > mostly RFCs (or their votings, or their pre-discussion) and sometimes > questions about the implementation or possible bugs. > > While emailing definitely works, it's not the best UX out there. Here are > some immediate flaws which make the process harder than it should be: > - having to subscribe to a mailing list to even see the discussions > - supporting public archives such as externals.io to expose discussions to > the public for those who aren't subscribed and keep historical data > - having to learn the specific, uncommon rules of replying: bottom > posting, word wrapping, removing footers. It's not to say any of those > rules are complex or hard to follow; it's that they're basically > inapplicable outside of emails, so they're usually not known by newcomers. > Also popular emailing clients don't do any of that automatically, making > each reply tedious. > - no way of editing a message. Mistakes will always be made, so being able > to quickly fix them would be nice > - no formatting, especially code blocks. Sure, they are possible through > HTML, but there's no single common way which all of the emailing clients > will understand - like Markdown > - no reactions - it's hard to tell whether something is supported or not. > This includes both the initiative being discussed and the replies that > follow. Sure, you can usually kind of judge the general narrative based on > the replies, but it's not always clear what's in favor. There are usually > many divergent branches of discussions and it's unknown what's supported > the most. > > Based on those issues and PHP, I propose moving the discussions elsewhere - > to some kind of modern platform. Since this is quite a big change in the > processes used, I imagine an RFC would be needed. But before I do that I > want to measure the reactions. If it goes well, I'll proceed with an RFC > draft. > > There are basically two choices here - a messenger-like platform (i.e. > Slack, Teams) or a developer focused platform like GitHub. While messengers > certainly work, they're more focused on working with teammates rather than > actual discussions. They usually don't have a simple way to navigate > publicly and are poor at separating multiple topics into threads. Some > projects use them for that purpose, but it's usually a worse experience > than what GitHub provides. > > GitHub is already used by PHP for both the source code and the issues, so > that is a good candidate, especially since it's a platform designed to > handle cases like this. Also, that should be a much easier transition now > that the source and issues were moved to GitHub. > > Also, to be clear: I'm not proposing to remove all PHP mailing lists; some > of them are one way (i.e. notifications for something) so they should > definitely stay that
Re: [PHP-DEV] Microseconds to error log
Hi Derick, Jakub and the team, Thank you so much for your input. Sorry for being so slow with this -- I haven't forgotten, it's just unfortunately, I'm not capable to handle all the things going around but I keep trying :) I did some research about why we keep using plain log files and our folks basically follow what Jakub said - we have our custom log collector (similar to Scribe, Fluentd and others) which has quite complicated routing rules and it was pretty straightforward to use files but adding Syslog adds undesirable complexity to this system. Although, it certainly doesn't look impossible. Speaking about backward compatibility stuff - I can think of another option, to postpone such a change till PHP v9.0, where we tend to introduce breaking changes. We are not a startup anymore - can wait for a couple of years. I saw the suggestion to draft an RFC for this to thoroughly walk through the question. I'm pretty open to this but it'll take a lot of time. So guys, do you feel it's feasible to do? I can imagine some people don't want to be harsh to say "please, stop this nonsense" :) I can see that this change might not bring a lot of value and appeared to be controversial so I'm fine to stop - we can keep this as our private patch. But if someone feels it might be something good, I can proceed with the RFC or something. Thank you for your patience so far. On Tue, Nov 29, 2022 at 11:43 AM Jakub Zelenka wrote: > > On Mon, Nov 28, 2022 at 4:13 PM Derick Rethans wrote: >> >> On Fri, 21 Oct 2022, Mikhail Galanin via internals wrote: >> > Looking into the future, probably we would like to have this format >> > configurable, if so it looks easy to do but still I can't see an easy >> > way to handle the microseconds issue. >> >> Making things configurable requires an ini setting, which we generally >> don't like to add. It wouldn't really work in this situation, as >> warnings/errors happen either before or during INI file parsing, meaning >> that it can't (yet) use the new format. >> > > I'm not sure I understand this because error_log itself is already > configurable using INI so obviously if the file path is specified there, then > the logged time format should be the same if configured in ini. By default > there is no error log so errors that happen before should not be logged > anyway. Or do I miss anything? > >> >> > Could you please help me to find the right way and share your thoughts >> > about this topic (maybe there are strong objections against such a >> > change)? >> >> I don't think we should change anything in PHP. Instead, use your >> system's syslog. You can configure PHP to send all warnings to syslog by >> setting "log_errors=1 error_log=syslog" in PHP.ini. In order to separate >> out just the PHP issues, you can also set "syslog.facility=local1" (or >> any other local). >> >> On Unix systems, you can configure syslog to add milliseconds to the log >> file messages. See https://askubuntu.com/a/1266114 >> >> If your system already uses systemd and journald, then you don't have to >> use any configuration settings, and you can query the journal with: >> >> journalctl -o short-iso-precise -r --facility=local1 >> >> A PHP warning would show up in there, with something like: >> >> $ sudo journalctl -o short-iso-precise -r --facility=local1 >> 2022-11-28T16:06:53.862980+ gargleblaster php[3143059]: PHP Warning: >> Undefined variable $fasd in Command line code on line 1 >> > > It is not always practical to use system log for PHP especially for users > using more than one FPM pool. Log files also offer some advantages like > easier export and post processing so I think there is still place for log > files and we should support the users that still use them which includes new > features like this one. > > Cheers > > Jakub -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Microseconds to error log
Hello good people,
(really hope I'm writing into the right thread this time).
I updated the patch considering the thoughts from this thread. Thank
you all for being so much responsive and helpful!
Meanwhile, there are two changes:
* Added function `php_format_timestamp' that takes microseconds part,
`php_format_date' remains unchanged to keep backward compatibility.
* Added INI `error_log_usec` = on|off (off by default) that changes
the timestamp.
Questions I have at the moment:
1. Naming (the most difficult part of our job, yeah) - does anyone
feel that they could suggest something better? Maybe someone can think
up something better, more clear/consistent with other parts of the
codebase?
2. The INI-thing. When initially I mentioned being configurable, I
realised that it could've been perceived in many different ways:
- we can enable/disable the microseconds
- we can choose from a pre-defined list of formats (PHP7, PHP7 + msec,
PHP7+ usec, ISO8601, ISO8601+usec, etc...)
- we also might want to use an Apache/HTTPd-like approach, e.g.
"[${time:format} $pid $hostname] $error_message"
Or, once we enable microseconds, we can switch to the ISO format, for
example (no, I don't like this approach but if we change the setting
name it might be not that confusing)
What do you think?
On Mon, Oct 31, 2022 at 10:16 AM Craig Francis wrote:
>
> On Sun, 30 Oct 2022 at 17:42, Rowan Tommins wrote:
>
> > In case of any confusion, I think this should be configurable as
> > "include microseconds: on / off", not configurable as "enter date format".
> >
>
>
> Any reason it can't be configured to use ISO 8601?
>
> Apache 2.4 allows you to use `LogFormat "...
> [%{%Y-%m-%dT%H:%M:%S}t.%{msec_frac}t] ..." format_name`
>
> https://httpd.apache.org/docs/trunk/mod/mod_log_config.html
>
> And MySQL uses "-MM-DDThh:mm:ss.uu":
>
> https://dev.mysql.com/doc/refman/8.0/en/error-log-format.html#error-log-format-system-variables
>
> When I'm doing some quick log checking, I often forget that PHP uses a
> different date format... admittedly, it can help having the month spelled
> out, so no one accidentally thinks it's the American format :-)
>
> Craig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Microseconds to error log
Hello everyone, I tried following Derrek's approach (to introduce a new function). A couple of considerations: We used to have some pain when this format changed last time (I can't remember details, unfortunately) but I don't feel like making an option to provide backward compatibility is a good idea. Early or lately, we will need to drop this compatibility and the users face absolutely the same issue. I hear people don't want to have this format configurable -- I tend to agree that it's a bit overcomplication. I'm not sure if I'm ready to switch to ISO8601 but if we have a consensus here, I'm open to updating the patch. Basically, I'm open to everything, please share your opinions. Pull-request: https://github.com/php/php-src/pull/9844 On Fri, Oct 21, 2022 at 11:46 AM Rowan Tommins wrote: > > On 21 October 2022 08:47:30 BST, Mikhail Galanin via internals > wrote: > >Basically, we have quite a high-loaded environment and we really want > >to see timestamps containing milli-/microseconds in our logs. > > > I'm not knowledgeable enough to comment on the implementation details, but > from a user point of view I agree the feature would be useful. It would > definitely need to be behind an ini setting, though, to avoid existing log > parsers failing unexpectedly on the new format. > > Regards, > Hi Mikhail, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Microseconds to error log
Description Hi there, I started this thread on GitHub but Christoph (cmb69) suggested this is the better place to discuss such a thing. (initial post: https://github.com/php/php-src/issues/9745) Basically, we have quite a high-loaded environment and we really want to see timestamps containing milli-/microseconds in our logs. It is easy to do for our custom logger but error messages from the PHP itself narrowed down to seconds (I'm talking about method php_log_err_with_severity() Link: https://github.com/php/php-src/blob/master/main/main.c#L799:~:text=php_log_err_with_severity In our repository, we have a hacky patch that adds microsecs in this log as well. Unfortunately, such a solution is not really a good approach to looking into the future. I wanted to adopt our patch to share it with the community and potentially merge it into upstream but stumbled upon the fact that it isn't really straightforward to format a date/time with microseconds using the standard API available for an extension. Basically, I found a couple of options: (1) We can instantiate a DateTime object and call DateTime::format(). It looks working but it makes the logging function way more complicated and potentially heavy (2) date_format works directly with timelib_time and can properly handle microsecs but it is hidden inside ext/date/php_date.c, Not really sure if it's a good idea to make it public (3) In theory, it is possible to add one more parameter to php_format_date but it'll break all the existing code. The change of signature doesn't look like a good option. However, we might be able to introduce another function if we want to encapsulate work with timelib_time within the ext/date. (4) Derrek Rethans suggested introducing a new function (e.g. php_format_date_ex) that takes care of usecs (see the thread on Github) Looking into the future, probably we would like to have this format configurable, if so it looks easy to do but still I can't see an easy way to handle the microseconds issue. Could you please help me to find the right way and share your thoughts about this topic (maybe there are strong objections against such a change)? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
