Re: [PHP-DEV] Release Managers for PHP 8.4
2024年3月6日(水) 0:41 Jakub Zelenka : > > Hi all, > > It's time to start the process of finding and electing RMs for the next minor > PHP release. > > We are looking for three souls to take on this role. Whomsoever is elected > will be guided and helped by the current, as well as previous RMs and the > excellent documentation in release-process.md [1]. > > Candidates should have a reasonable knowledge of internals, be confident > about merging pull requests without breaking backward compatibility, doing > triage for bugs, liaising with previous release managers, and generally > getting the branch in good shape, as these are among the activities you will > be undertaking as release manager. Ideally, at least one of candidate should > be a core developer that can assess more technical PR's. Other candidates do > not necessarily need to have deep knowledge of internals but should > understand above mentioned points. > > Notably, at least one of the volunteers must be a "veteran" release manager, > meaning they have participated in at least one release of PHP in the past. > The other may be an additional veteran, or more ideally, someone new to the > RM role (in order to increase our supply of veteran RMs). > > Please put your name forward here if you wish to be considered a candidate. > An initial TODO page has been added to the wiki and contains provisional > dates for GA and pre-releases [2]. > > [1] https://github.com/php/php-src/blob/master/docs/release-process.md > [2] https://wiki.php.net/todo/php84 > > Let's all make PHP awesome! > Jakub Zelenka, Eric Mann & Pierrick Charron > Hello, all. I would like to candidacy to Release Manager for PHP 8.4. I created mb_trim functions for since PHP 8.4. There may also be mb_ucfirst and mb_lcfirst functions add to them. I also have other ideas, such as the grapheme_str_split function, and I would like to take care of them if they are included in PHP 8.4. I'm not necessarily familiar with the internals of Zend Engine, but I'm proud that I've taken particular care in maintaining versions. Also, My company (Cybozu Inc.) I currently work for understands my PHP Internals activities and gives me time, so I would like to contribute further. Regards Yuya Hamada -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
2024年3月6日(水) 9:22 youkidearitai :
>
> Hi, Larry
> Hi, Niels
>
> 2024年3月6日(水) 6:47 Niels Dossche :
> >
> > Hi Larry
> > Hi Yuya
> >
> > So first of all, I meant the error handling in cases like these:
> > https://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea5605f38dde4bcb6a016865130590e45e23202eR852-R860
> > The implementation still returns NULL here, so the signature is still
> > incorrect. Either it should return false to match the other functions, or
> > throw something and not return a value.
> >
> > On 05/03/2024 18:40, Larry Garfield wrote:
> > > On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
> > >> 2024年3月5日(火) 5:52 Niels Dossche :
> > >>>
> > >>> Hi Yuya
> > >>>
> > >>> This sounds useful.
> > >>>
> > >>> I do have a question about the function signature:
> > >>> function grapheme_str_split(string $string, int $length = 1): array {}
> > >>>
> > >>> This always returns an array.
> > >>> However, looking at your PR it seems you return NULL on failure, but
> > >>> the return type in the signature isn't nullable.
> > >>> Also, from a quick look, it seems other functions return false instead
> > >>> of null on failure. So perhaps the return type should be array|false.
> > >>>
> > >>> What do you think? :)
> > >>>
> > >>> Kind regards
> > >>> Niels
> > >>>
> > >>> On 03/03/2024 00:21, youkidearitai wrote:
> > Hi, Internals
> >
> > I noticed PHP does not have grapheme cluster for str_split function.,
> > Until now, you had to use the PCRE function's \X.
> >
> > Therefore, I try create `grapheme_str_split` function.
> > https://github.com/php/php-src/pull/13580
> > It is possible to convert array per emoji and variation selectors
> > using ICU.
> >
> > If it's fine, I'll create an RFC.
> >
> > Regards
> > Yuya
> >
> > >>
> > >> Hi, Niels
> > >>
> > >> Thank you for your comment.
> > >> Indeed, returns false is make sense.
> > >>
> > >> Therefore, I changed to returns false when invalid UTF-8 strings.
> > >>
> > >> Regards
> > >> Yuya
> > >
> > > Many legacy functions return false on error, but that is widely regarded
> > > as bad design. Please do not continue bad design.
> >
> > I agree that returning false on error isn't ideal for exceptional cases,
> > that's what exceptions are for.
> > Looking at the other grapheme functions makes me wonder though how
> > consistent this would be, especially w.r.t. intl_get_error_*() and
> > intl_error_name().
> >
> > >
> > > Right now, the best "standard" error handling mechanism available is
> > > exceptions. false (or null) can very easily lead to incorrectly using
> > > that value as though it were valid, when it's not, which will sometimes
> > > cause a fatal error and sometimes cause a security leak.
> > >
> > > If the input value cannot be logically processed, that's an exception.
> > > (Or Error, perhaps.)
> > >
> > > --Larry Garfield
> >
> > Kind regards
> > Niels
>
> Thank you so much for advice.
> Indeed, This current grapheme* functions seems inconsistent.
>
> Therefore, it's one thing when returns null, throws any exception.
> Shall we do so just for the grapheme_str_split function?
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
Ah, If throws exception when intl_error*, is required other an RFC?
If we make grapheme_str_split's signature is below (include null):
```
function grapheme_str_split(string $string, int $length = 1): array|null {}
```
For now, I change signature to `array|null`.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
Hi, Larry
Hi, Niels
2024年3月6日(水) 6:47 Niels Dossche :
>
> Hi Larry
> Hi Yuya
>
> So first of all, I meant the error handling in cases like these:
> https://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea5605f38dde4bcb6a016865130590e45e23202eR852-R860
> The implementation still returns NULL here, so the signature is still
> incorrect. Either it should return false to match the other functions, or
> throw something and not return a value.
>
> On 05/03/2024 18:40, Larry Garfield wrote:
> > On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
> >> 2024年3月5日(火) 5:52 Niels Dossche :
> >>>
> >>> Hi Yuya
> >>>
> >>> This sounds useful.
> >>>
> >>> I do have a question about the function signature:
> >>> function grapheme_str_split(string $string, int $length = 1): array {}
> >>>
> >>> This always returns an array.
> >>> However, looking at your PR it seems you return NULL on failure, but the
> >>> return type in the signature isn't nullable.
> >>> Also, from a quick look, it seems other functions return false instead of
> >>> null on failure. So perhaps the return type should be array|false.
> >>>
> >>> What do you think? :)
> >>>
> >>> Kind regards
> >>> Niels
> >>>
> >>> On 03/03/2024 00:21, youkidearitai wrote:
> Hi, Internals
>
> I noticed PHP does not have grapheme cluster for str_split function.,
> Until now, you had to use the PCRE function's \X.
>
> Therefore, I try create `grapheme_str_split` function.
> https://github.com/php/php-src/pull/13580
> It is possible to convert array per emoji and variation selectors using
> ICU.
>
> If it's fine, I'll create an RFC.
>
> Regards
> Yuya
>
> >>
> >> Hi, Niels
> >>
> >> Thank you for your comment.
> >> Indeed, returns false is make sense.
> >>
> >> Therefore, I changed to returns false when invalid UTF-8 strings.
> >>
> >> Regards
> >> Yuya
> >
> > Many legacy functions return false on error, but that is widely regarded as
> > bad design. Please do not continue bad design.
>
> I agree that returning false on error isn't ideal for exceptional cases,
> that's what exceptions are for.
> Looking at the other grapheme functions makes me wonder though how consistent
> this would be, especially w.r.t. intl_get_error_*() and intl_error_name().
>
> >
> > Right now, the best "standard" error handling mechanism available is
> > exceptions. false (or null) can very easily lead to incorrectly using that
> > value as though it were valid, when it's not, which will sometimes cause a
> > fatal error and sometimes cause a security leak.
> >
> > If the input value cannot be logically processed, that's an exception. (Or
> > Error, perhaps.)
> >
> > --Larry Garfield
>
> Kind regards
> Niels
Thank you so much for advice.
Indeed, This current grapheme* functions seems inconsistent.
Therefore, it's one thing when returns null, throws any exception.
Shall we do so just for the grapheme_str_split function?
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
Hi Larry
Hi Yuya
So first of all, I meant the error handling in cases like these:
https://github.com/php/php-src/pull/13580/files#diff-b8fe038d9d7539694593978bea5605f38dde4bcb6a016865130590e45e23202eR852-R860
The implementation still returns NULL here, so the signature is still
incorrect. Either it should return false to match the other functions, or throw
something and not return a value.
On 05/03/2024 18:40, Larry Garfield wrote:
> On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
>> 2024年3月5日(火) 5:52 Niels Dossche :
>>>
>>> Hi Yuya
>>>
>>> This sounds useful.
>>>
>>> I do have a question about the function signature:
>>> function grapheme_str_split(string $string, int $length = 1): array {}
>>>
>>> This always returns an array.
>>> However, looking at your PR it seems you return NULL on failure, but the
>>> return type in the signature isn't nullable.
>>> Also, from a quick look, it seems other functions return false instead of
>>> null on failure. So perhaps the return type should be array|false.
>>>
>>> What do you think? :)
>>>
>>> Kind regards
>>> Niels
>>>
>>> On 03/03/2024 00:21, youkidearitai wrote:
Hi, Internals
I noticed PHP does not have grapheme cluster for str_split function.,
Until now, you had to use the PCRE function's \X.
Therefore, I try create `grapheme_str_split` function.
https://github.com/php/php-src/pull/13580
It is possible to convert array per emoji and variation selectors using
ICU.
If it's fine, I'll create an RFC.
Regards
Yuya
>>
>> Hi, Niels
>>
>> Thank you for your comment.
>> Indeed, returns false is make sense.
>>
>> Therefore, I changed to returns false when invalid UTF-8 strings.
>>
>> Regards
>> Yuya
>
> Many legacy functions return false on error, but that is widely regarded as
> bad design. Please do not continue bad design.
I agree that returning false on error isn't ideal for exceptional cases, that's
what exceptions are for.
Looking at the other grapheme functions makes me wonder though how consistent
this would be, especially w.r.t. intl_get_error_*() and intl_error_name().
>
> Right now, the best "standard" error handling mechanism available is
> exceptions. false (or null) can very easily lead to incorrectly using that
> value as though it were valid, when it's not, which will sometimes cause a
> fatal error and sometimes cause a security leak.
>
> If the input value cannot be logically processed, that's an exception. (Or
> Error, perhaps.)
>
> --Larry Garfield
Kind regards
Niels
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Hi On 3/5/24 14:09, Hans Henrik Bergan wrote: I don't want to spend too much effort on nitpicks, but if someone volunteers to improve it, I'd be happy to add it, in which case please send a PR to https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md To set my email in context: For me visuals play an important role in the overall presentation of an RFC. If it's not properly formatted, it's harder to read and harder to understand the RFC. Proper formatting also is some indicator that the author actually cares about the RFC instead of just throwing stuff over the fence and letting others figure out the details. This one is simple enough and it's certainly not something that makes me vote “No” out of spite, but perhaps this is something to keep in mind for future RFCs. For (2) it would help if you'd explain what it means for sleep() to be interrupted and how this can happen. I believe this is signal-handling related, but writing it out explicitly for the folks that didn't yet encounter it would probably make sense. I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, […] I don't know how to make it return 192 on Windows.. Anyone know? My remark was not just about Windows (I can't advice here either, I don't do Windows), adding a short *nix explanation of when sleep will return earlier than expected would be helpful as well. That's likely the more common case anyway. I'd just put a single "Do all of this in the next minor" vote there. All of the suggested improvements make sense to me and the breaking changes are mostly theoretical. meh, I don't want to risk the RFC getting rejected because too many people thought it should be done in next.major instead of next.minor, let's keep both next.minor + next.major vote options. (You're probably right, I predict a majority vote for next.minor for all 3, but i'll keep the vote options just in case.) Complicated voting options also risk the RFC getting rejected, especially if certain combinations of voting options are non-sense (such as 1: yes, 2: yes, 3: no). Personally I'd rather have no change at all, instead of a half-baked internally inconsistent change. Don't forgot to open up a dedicated explicit discussion thread once you move it into the "Discussion" phase. How would I even do that? Linking to https://externals.io/message/122388 isn't sufficient? Once you are happy with the RFC contents, instead of replying to this existing thread, send a fresh email to the list, titled "RFC: Support for Floats in Sleep Function", in there link the RFC and this discussion thread and say that the discussion period is starting now. This will ensure it will pop up as a fresh email for the folks who already ignored the subthread, because they were not interested in the pre-RFC discussion while stuff is still in flux. Best regards Tim Düsterhus
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Tue, Mar 5, 2024, at 1:09 PM, Hans Henrik Bergan wrote: > Voting has now been simplified to 3x no/php 8.4/php 9.0 questions. > (I actually would've preferred the original 6, would have been > unambiguous if people are supposed to checkbox only 8.4 or both 8.4 > and 9.0, and would have been easier to see the % of people who voted > only 9.0, I think. But I don't care enough about it to actually fight > for it, and multiple people requested it be reduced to 3, so let's go > with that :) ) > >>That said, thanks for making this, it's something I'd like to see in PHP as >>well. > > Happy to hear it :) > > >> - Instead of using backticks, use `sleep()` for inline and > `…` for multi-line snippets. This comes with syntax > highlighting and documentation links. >>(...) >> - It would help readability if you'd use additional headlines for each > of the three sub-proposals within the Proposal section. >> > > I don't want to spend too much effort on nitpicks, but if someone > volunteers to improve it, I'd be happy to add it, in which case please > send a PR to > https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md > >> For (2) it would help if you'd explain what it means for sleep() to be > interrupted and how this can happen. I believe this is signal-handling > related, but writing it out explicitly for the folks that didn't yet > encounter it would probably make sense. > > I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, > I couldn't actually get it to return 192. (nor return anything except 0): > - When sending a WM_CLOSE message (equivalent to `taskkill /IM > php.exe`), it was just completely ignored: PHP kept sleeping. > - When doing a TerminateProcess() call (equivalent to `taskkill /IM > php.exe /F`), PHP was just terminated, sleep never returned. > - When sending a CTRL_C_EVENT (equivalent to ctrl+C), PHP just > terminated, sleep never returned. > - When sending a CTRL_BREAK_EVENT (equivalent to ctrl+Break), PHP just > terminated, sleep never returned. > > I don't know how to make it return 192 on Windows.. Anyone know? > >>For the "Unaffected PHP Functionality" you could just spell out that anything >>that is not the sleep() function will be unaffected > > meh, someone else pointed out that the irrelevant sections could be > removed, I removed the "Unaffected PHP Functionality" section (along > with 2-3 others) > >> I'd just put a single "Do all of this in the next minor" vote there. All >>of the suggested improvements make sense to me and the breaking changes >>are mostly theoretical. > > meh, I don't want to risk the RFC getting rejected because too many > people thought it should be done in next.major instead of next.minor, > let's keep both next.minor + next.major vote options. (You're probably > right, I predict a majority vote for next.minor for all 3, but i'll > keep the vote options just in case.) A 3 way up-down vote doesn't make sense. What happens if none of the 3 options reaches 66%? The viable options here are a single RCV vote (which we've done before), or a single "Should we do this" vote that requires 66%, followed by a "when should we do this" vote with 2 options, majority wins. --Larry Garfield
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
On Tue, Mar 5, 2024, at 7:25 AM, youkidearitai wrote:
> 2024年3月5日(火) 5:52 Niels Dossche :
>>
>> Hi Yuya
>>
>> This sounds useful.
>>
>> I do have a question about the function signature:
>> function grapheme_str_split(string $string, int $length = 1): array {}
>>
>> This always returns an array.
>> However, looking at your PR it seems you return NULL on failure, but the
>> return type in the signature isn't nullable.
>> Also, from a quick look, it seems other functions return false instead of
>> null on failure. So perhaps the return type should be array|false.
>>
>> What do you think? :)
>>
>> Kind regards
>> Niels
>>
>> On 03/03/2024 00:21, youkidearitai wrote:
>> > Hi, Internals
>> >
>> > I noticed PHP does not have grapheme cluster for str_split function.,
>> > Until now, you had to use the PCRE function's \X.
>> >
>> > Therefore, I try create `grapheme_str_split` function.
>> > https://github.com/php/php-src/pull/13580
>> > It is possible to convert array per emoji and variation selectors using
>> > ICU.
>> >
>> > If it's fine, I'll create an RFC.
>> >
>> > Regards
>> > Yuya
>> >
>
> Hi, Niels
>
> Thank you for your comment.
> Indeed, returns false is make sense.
>
> Therefore, I changed to returns false when invalid UTF-8 strings.
>
> Regards
> Yuya
Many legacy functions return false on error, but that is widely regarded as bad
design. Please do not continue bad design.
Right now, the best "standard" error handling mechanism available is
exceptions. false (or null) can very easily lead to incorrectly using that
value as though it were valid, when it's not, which will sometimes cause a
fatal error and sometimes cause a security leak.
If the input value cannot be logically processed, that's an exception. (Or
Error, perhaps.)
--Larry Garfield
[PHP-DEV] Re: Release Managers for PHP 8.4
On Tue, Mar 5, 2024 at 3:37 PM Jakub Zelenka wrote: > Hi all, > > It's time to start the process of finding and electing RMs for the next > minor PHP release. > > We are looking for three souls to take on this role. Whomsoever is elected > will be guided and helped by the current, as well as previous RMs and the > excellent documentation in release-process.md [1]. > > Candidates should have a reasonable knowledge of internals, be confident > about merging pull requests without breaking backward compatibility, doing > triage for bugs, liaising with previous release managers, and generally > getting the branch in good shape, as these are among the activities you > will be undertaking as release manager. Ideally, at least one of > candidate should be a core developer that can assess more technical PR's. > Other candidates do not necessarily need to have deep knowledge of > internals but should understand above mentioned points. > > Notably, at least one of the volunteers must be a "veteran" release > manager, meaning they have participated in at least one release of PHP in > the past. The other may be an additional veteran, or more ideally, someone > new to the RM role (in order to increase our supply of veteran RMs). > > Please put your name forward here if you wish to be considered a > candidate. An initial TODO page has been added to the wiki and contains > provisional dates for GA and pre-releases [2]. > > [1] https://github.com/php/php-src/blob/master/docs/release-process.md > [2] https://wiki.php.net/todo/php84 > > Let's all make PHP awesome! > Jakub Zelenka, Eric Mann & Pierrick Charron > > Apology I forgot add the deadline for the volunteer search and the voting phase: Applications will be accepted until 31 March 2024 12:00:00 UTC Elections (if needed) will start on 1 April and run until 15 April 12:00:00 UTC Cheers Jakub
[PHP-DEV] Release Managers for PHP 8.4
Hi all, It's time to start the process of finding and electing RMs for the next minor PHP release. We are looking for three souls to take on this role. Whomsoever is elected will be guided and helped by the current, as well as previous RMs and the excellent documentation in release-process.md [1]. Candidates should have a reasonable knowledge of internals, be confident about merging pull requests without breaking backward compatibility, doing triage for bugs, liaising with previous release managers, and generally getting the branch in good shape, as these are among the activities you will be undertaking as release manager. Ideally, at least one of candidate should be a core developer that can assess more technical PR's. Other candidates do not necessarily need to have deep knowledge of internals but should understand above mentioned points. Notably, at least one of the volunteers must be a "veteran" release manager, meaning they have participated in at least one release of PHP in the past. The other may be an additional veteran, or more ideally, someone new to the RM role (in order to increase our supply of veteran RMs). Please put your name forward here if you wish to be considered a candidate. An initial TODO page has been added to the wiki and contains provisional dates for GA and pre-releases [2]. [1] https://github.com/php/php-src/blob/master/docs/release-process.md [2] https://wiki.php.net/todo/php84 Let's all make PHP awesome! Jakub Zelenka, Eric Mann & Pierrick Charron
Re: [PHP-DEV] php-src docs
On Tue, Mar 5, 2024 at 1:48 PM Peter Kokot wrote: > > On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo wrote: > > > > Hi Yuya > > > > It seems you accidentally sent your response to me instead of the list. > > > > On Sun, Feb 11, 2024 at 5:10 PM youkidearitai > > wrote: > > > > > > 2024年2月11日(日) 21:18 Ilija Tovilo : > > > > > > > > Hi everyone. > > > > > > > > I would like to start an initiative to centralize documentation of the > > > > PHP internals. > > > > https://github.com/php/php-src/pull/13338 > > > > https://iluuu1994.github.io/php-src/ (will be moved to php.github.io > > > > once merged) > > > > > > > > Let me know of any thoughts and suggestions you might have. > > > > > > Hi, Ilija. > > > Thank you for your great suggestion. > > > > > > It seems make sense to have a set of documents about the structure of > > > php-src in php-src. > > > Easily create pull requests to them. > > > > > > Although I have to learn reStructuredText, It is not seems major problem. > > > > For some context, I initially planned to go with the mdBook from the > > Rust project (https://github.com/rust-lang/mdBook/) as Markdown is a > > bit more approachable. After writing the sample zval chapter, I > > noticed some pain points in terms of formatting, most significantly > > tables. That said, reStructuredText is far from perfect itself. > > > > As mentioned previously, the other reason for choosing Sphinx was that > > it is quite extensible. > > > > Ilija > > Wouldn't it be simpler and better in the long run to have a separate > Git repository for the PHP language internal documentation? Because > once this will increase in number of files, also php-...tar.gz archive > files will increase and everything will become more complex. It will > also mess the php-src Git log with documentation changes. And the docs > subdirectory in the php-src can be still used for some possible other > files that are needed for the GitHub interface usage. Now we have the > docs-old subdirectory in php-src, which is a bit messy and it might > take a while to migrate all those to RST. It would be also perhaps > smart to sync this initiative with https://github.com/php/php-langspec > somehow or at least to display all of those together in some GH page. Personally, the documentation is part of the code it documents, otherwise, you don't have documentation, you have content that can be mistaken for documentation. Robert Landers Software Engineer Utrecht NL
Re: [PHP-DEV] php-src docs
Hi, On Tue, 5 Mar 2024 at 12:48, Peter Kokot wrote: > On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo wrote: > > > > Hi Yuya > > > > It seems you accidentally sent your response to me instead of the list. > > > > On Sun, Feb 11, 2024 at 5:10 PM youkidearitai > wrote: > > > > > > 2024年2月11日(日) 21:18 Ilija Tovilo : > > > > > > > > Hi everyone. > > > > > > > > I would like to start an initiative to centralize documentation of > the > > > > PHP internals. > > > > https://github.com/php/php-src/pull/13338 > > > > https://iluuu1994.github.io/php-src/ (will be moved to php.github.io > > > > once merged) > > > > > > > > Let me know of any thoughts and suggestions you might have. > > > > > > Hi, Ilija. > > > Thank you for your great suggestion. > > > > > > It seems make sense to have a set of documents about the structure of > > > php-src in php-src. > > > Easily create pull requests to them. > > > > > > Although I have to learn reStructuredText, It is not seems major > problem. > > > > For some context, I initially planned to go with the mdBook from the > > Rust project (https://github.com/rust-lang/mdBook/) as Markdown is a > > bit more approachable. After writing the sample zval chapter, I > > noticed some pain points in terms of formatting, most significantly > > tables. That said, reStructuredText is far from perfect itself. > > > > As mentioned previously, the other reason for choosing Sphinx was that > > it is quite extensible. > > > > Ilija > > Wouldn't it be simpler and better in the long run to have a separate > Git repository for the PHP language internal documentation? The problem with this is that it gets easily outdated. If it’s in the same repo, we can ask for updates during PR and have it as part of review. Because > once this will increase in number of files, also php-...tar.gz archive > files will increase and everything will become more complex. Are you talking about release tarball that RM creates or git archive (github) one? If the former, then we can filter the docs out and if latter, than I’m not sure why we should care? It will > also mess the php-src Git log with documentation changes. The way how I see it is that internal docs are part of code or its addition so I wouldn’t think it can mess up our git logs that are largely irrelevant anyway. And the docs > subdirectory in the php-src can be still used for some possible other > files that are needed for the GitHub interface usage. Now we have the > docs-old subdirectory in php-src, which is a bit messy and it might > take a while to migrate all those to RST. It would be also perhaps > smart to sync this initiative with https://github.com/php/php-langspec Isn’t this dead and hugely outdated? Cheers Jakub
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
Voting has now been simplified to 3x no/php 8.4/php 9.0 questions. (I actually would've preferred the original 6, would have been unambiguous if people are supposed to checkbox only 8.4 or both 8.4 and 9.0, and would have been easier to see the % of people who voted only 9.0, I think. But I don't care enough about it to actually fight for it, and multiple people requested it be reduced to 3, so let's go with that :) ) >That said, thanks for making this, it's something I'd like to see in PHP as >well. Happy to hear it :) > - Instead of using backticks, use `sleep()` for inline and `…` for multi-line snippets. This comes with syntax highlighting and documentation links. >(...) > - It would help readability if you'd use additional headlines for each of the three sub-proposals within the Proposal section. > I don't want to spend too much effort on nitpicks, but if someone volunteers to improve it, I'd be happy to add it, in which case please send a PR to https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md > For (2) it would help if you'd explain what it means for sleep() to be interrupted and how this can happen. I believe this is signal-handling related, but writing it out explicitly for the folks that didn't yet encounter it would probably make sense. I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2, I couldn't actually get it to return 192. (nor return anything except 0): - When sending a WM_CLOSE message (equivalent to `taskkill /IM php.exe`), it was just completely ignored: PHP kept sleeping. - When doing a TerminateProcess() call (equivalent to `taskkill /IM php.exe /F`), PHP was just terminated, sleep never returned. - When sending a CTRL_C_EVENT (equivalent to ctrl+C), PHP just terminated, sleep never returned. - When sending a CTRL_BREAK_EVENT (equivalent to ctrl+Break), PHP just terminated, sleep never returned. I don't know how to make it return 192 on Windows.. Anyone know? >For the "Unaffected PHP Functionality" you could just spell out that anything >that is not the sleep() function will be unaffected meh, someone else pointed out that the irrelevant sections could be removed, I removed the "Unaffected PHP Functionality" section (along with 2-3 others) > I'd just put a single "Do all of this in the next minor" vote there. All >of the suggested improvements make sense to me and the breaking changes >are mostly theoretical. meh, I don't want to risk the RFC getting rejected because too many people thought it should be done in next.major instead of next.minor, let's keep both next.minor + next.major vote options. (You're probably right, I predict a majority vote for next.minor for all 3, but i'll keep the vote options just in case.) >I don't think I've ever seen anything using the return value of sleep(). same here. >Don't forgot to open up a dedicated explicit discussion thread once you move >it into the "Discussion" phase. How would I even do that? Linking to https://externals.io/message/122388 isn't sufficient?
Re: [PHP-DEV] php-src docs
On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo wrote: > > Hi Yuya > > It seems you accidentally sent your response to me instead of the list. > > On Sun, Feb 11, 2024 at 5:10 PM youkidearitai wrote: > > > > 2024年2月11日(日) 21:18 Ilija Tovilo : > > > > > > Hi everyone. > > > > > > I would like to start an initiative to centralize documentation of the > > > PHP internals. > > > https://github.com/php/php-src/pull/13338 > > > https://iluuu1994.github.io/php-src/ (will be moved to php.github.io > > > once merged) > > > > > > Let me know of any thoughts and suggestions you might have. > > > > Hi, Ilija. > > Thank you for your great suggestion. > > > > It seems make sense to have a set of documents about the structure of > > php-src in php-src. > > Easily create pull requests to them. > > > > Although I have to learn reStructuredText, It is not seems major problem. > > For some context, I initially planned to go with the mdBook from the > Rust project (https://github.com/rust-lang/mdBook/) as Markdown is a > bit more approachable. After writing the sample zval chapter, I > noticed some pain points in terms of formatting, most significantly > tables. That said, reStructuredText is far from perfect itself. > > As mentioned previously, the other reason for choosing Sphinx was that > it is quite extensible. > > Ilija Wouldn't it be simpler and better in the long run to have a separate Git repository for the PHP language internal documentation? Because once this will increase in number of files, also php-...tar.gz archive files will increase and everything will become more complex. It will also mess the php-src Git log with documentation changes. And the docs subdirectory in the php-src can be still used for some possible other files that are needed for the GitHub interface usage. Now we have the docs-old subdirectory in php-src, which is a bit messy and it might take a while to migrate all those to RST. It would be also perhaps smart to sync this initiative with https://github.com/php/php-langspec somehow or at least to display all of those together in some GH page.
[PHP-DEV] Changes to ML - only subscribed addresses can send to it
Hello, This is an information message. As some of you are aware there has been some changes to ML. I just stumbled on one of the changes when sending 8.3.4RC1 emails so want to let others know. The change is that the list will accept only messages from the subscribers which means that From header must match the address that is subscribed to the mailing list when sending email. This might affect PHP VCS holders that set From to PHP email address and are subscribed from different address (usually alias for PHP address) as I do. In such case the easiest solution is to unsubscribe the different address and subscribe the PHP address. Hope this helps to prevent some surprises like I just had! :) Regards Jakub
[PHP-DEV] PHP 8.3.4RC1 available for testing
This is my third attempt to send this so hopefully third time lucky. :) PHP 8.3.4RC1 has just been released and can be downloaded from: https://downloads.php.net/~jakub/ or https://qa.php.net/ or use the git tag: php-8.3.4RC1 Windows binaries are available at: https://windows.php.net/qa/#php-8.3 Please test it carefully, and report any bugs to https://github.com/php/php-src/issues PHP 8.3.4 should be expected in 2 weeks, i.e. on March 14, 2024. Hash values and PGP signatures can be found below or at https://gist.github.com/bukka/ecd793db8b73d6afc3e538bccf43 Thank you, and happy testing! Regards, Jakub Zelenka, Eric Mann & Pierrick Charron php-8.3.4RC1.tar.bz2 SHA256 hash: cbe898e2ae54ab6e3adf38c6300d84dca1dce163c1bc417a799b162f5e44d025 PGP signature: -BEGIN PGP SIGNATURE- iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZd8eQAAKCRAcB3ncXAqd 5LPsAQCgBDlJofzcqVBRL9Zkan9aNKA3MJMF1Arvkt1KrlS0ugEAl3G+Pwp7JfNO Yrjwgwno0M+n+/Qf5t00jPImECWR6gA= =T4nt -END PGP SIGNATURE- php-8.3.4RC1.tar.gz SHA256 hash: 05189cecdacdce87b106d0106aa22dda2f78ef02b5f1cf30f40724ec07f1a929 PGP signature: -BEGIN PGP SIGNATURE- iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZd8eQAAKCRAcB3ncXAqd 5Eq8AQCRkYMIcZYk8XEaySG36M+WS4sxqCp9iAUAdVzdAe7KAgEAkXxc9Op0woKZ HQ815r7hSaT0bKSQQmd2Dzntyyf36w0= =d1Lc -END PGP SIGNATURE- php-8.3.4RC1.tar.xz SHA256 hash: 91bf2015e36907497ca50112ed5e636781d55bbac5be71984aff1662cfac1fc0 PGP signature: -BEGIN PGP SIGNATURE- iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZd8eQQAKCRAcB3ncXAqd 5NZAAP9m0EqlnpeA24Cfq8fr6UJOBPNlo9biB2IorKOQ7LUReQD6A8868sBKL+61 9MBSnLHNK0EE/Cr0NqSqFylpAOsZ5g4= =cGc9 -END PGP SIGNATURE-
Re: [PHP-DEV] [Discussion] grapheme cluster for str_split function
>
> Hi, Niels
>
> Thank you for your comment.
> Indeed, returns false is make sense.
>
> Therefore, I changed to returns false when invalid UTF-8 strings.
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
Sorry, again.
I checked behavior of mb_str_split function. So Illegal byte sequences
are returned as is.
```
sapi/cli/php -r 'var_dump(mb_str_split("あ\xc2\xf4\x80あ"));'
array(4) {
[0]=>
string(3) "あ"
[1]=>
string(2) "��"
[2]=>
string(1) "�"
[3]=>
string(3) "あ"
}
```
And, I reading ICU document about utext_openUTF8 (below is link):
https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/utext_8h.html#a130e7cba201c4b38799b432eb269f6d5
> Any invalid UTF-8 in the input will be handled in this way: a sequence of
> bytes that has the form of a truncated, but otherwise valid, UTF-8 sequence
> will be replaced by a single unicode replacement character, \uFFFD. Any other
> illegal bytes will each be replaced by a \uFFFD.
Therefore, I think encoding check is not need.
Returns only arrays together with mb_str_split.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-
