@ocramius @j3j5 @klimpong In Docker everything except for a port is going to be messy for health checks then. Accessing the file system is not intended and even if you would, nothing would guarantee that the exposed port for the actual service is functional. Basically any out-of-band health checks are going to lie.

@j3j5 @ocramius @klimpong Yesn't. You would not use the systemd-notify binary (except in a shell script), but rather communicate directly with the notify socket.

@ocramius @klimpong systemd allows you to enable a per-service watchdog where the process will need to regularly send pings to systemd to indicate it still is alive. See https://0pointer.de/blog/projects/watchdog.html

@heiglandreas @derickr But even if you used `str_contains()`, your example would be incorrect. mbstring supports UTF-16. For UTF-16 `瀀` is contained within `pe` when performing a naive byte-wise comparison after normalizing:

var_dump(str_contains(mb_strtolower("\x00\x70\x00\x65", "UTF-16"), mb_strtolower("\x70\x00", "UTF-16")));

@heiglandreas @derickr The fact that your example uses `stripos` (the ASCII-case-insensitive variant of `strpos`) after lowercasing with `mb_` functions probably is a good indicator why adding new functions that result in “less typing” are a good thing.

@heiglandreas Yes, there is: ẞ (that is U+1E9E). Nevertheless the Unicode project (currently) defines the uppercasing of `ß` to be `SS` and that's also what is implemented by, e.g. Rust:

https://doc.rust-lang.org/std/string/struct.String.html#method.to_uppercase

The uppercase ẞ is also an official part of the German language since 2017:

https://en.wikipedia.org/wiki/%C3%9F#Development_of_a_capital_form

@heiglandreas @derickr PHP’s strings are well-understood to be byte-strings and PHP’s string functions are well-understood to work on bytes or ASCII.

It's 2025 and we really shouldn't be introducing more inconsistency into the language. Multi-byte-aware functions should be in `mb_` or `grapheme_`, but that shouldn't block adding new functions working on bytes or ASCII.

@heiglandreas @derickr As an example of a modern programming language: Rust’s `String` type has various `_ascii` methods, likely because dealing with ASCII-only case folding is sufficient in many cases.

@heiglandreas @derickr I disagree. When dealing with identifiers, ASCII (particularly printable ASCII) is ubiquitous and this will likely not change any time soon (if ever).

I do not want my functions dealing with these identifiers to be locale-dependent. I also don't want to go through a heavy Unicode-aware function that needs to handle cases like `ß` getting uppercased to `SS` and thus changing the length of the output.

@ilutov @Crell @jaapio I really should've argued more strongly against the set-shorthand 😕

@markusstaab I'm not even sure what the semantics of deprecating a parameter should be. Deprecating a parameter in the middle of the parameter list clearly is impossible.

Deprecating a parameter at the end of the parameter list might be, but it would still be hard for the user to use the function in a cross-version way without triggering the deprecation.

🥧 I have finally released PIE 1.0.0 - The PHP Installer for Extensions will let you install a growing number of extensions. Thank you to a whole host of people for their support in building this excellent @thephpf initiative! ❤️

#phppie #pie #phpcommunity #phpc
https://github.com/php/pie/releases/tag/1.0.0

@ocramius @sebastian The bananas?

@heiglandreas @Girgias Even without strict-typing PHP only allows “lossless” conversions. It's called “not strict-types”, not “no types”.

@heiglandreas `null` indicates the absence of a value. The difference between “not making a decision” and “explicitly deciding on providing an empty value” can be meaningful (there is a difference between “not sending an email” and “sending an empty email”), thus the implicit conversion is disallowed.

For integers, including `0` there is only one reasonable string interpretation.

/cc @Girgias

Fittingly, with PHP's birthday today, we will have the kick-off meeting of the #PHP8_5 release managers today.

Excited to give back to php-src in this way as well over the next couple of years.

Thankful to @Tideways for supporting PHP through contributions, financially and supporting me in doing this.

@zan @ramsey To me even the *chance* of pitfalls is plenty of reason not to do it. Tags in git are super cheap and you would need to rebuild the release artifacts either way.

@zan @ramsey The tag will not update for folks who already have pulled the repository since then, possibly leading to confusion what exact commit one is referring to when one is referencing a tag.

Updating a pushed tag generally is a no-no.

@lordsimal Containers are started with `--rm` (this cleaned up automatically) and networks are only created once. The only thing that needs clean-up is images, which I do manually semi-regularly.

https://www.mail-archive.com/haproxy@formilux.org/msg45917.html #HAProxy 3.2.0 was released, featuring an experimental ACME client, real QUIC support for OpenSSL 3.5 and a lot of other stuff.