[00:28:03] <legoktm>	 TimStarling: thanks for the excimer review, whenever you have time I need a bit of help with https://gerrit.wikimedia.org/r/c/mediawiki/php/wmerrors/+/752361, specifically figuring out how to fix a warning regarding call_user_function_ex
[00:29:00] <TimStarling>	 we don't need or use wmerrors anymore
[00:29:10] <TimStarling>	 it can just be archived
[00:29:29] <legoktm>	 oh?
[00:30:01] <legoktm>	 it's still deployed...
[00:30:19] <legoktm>	 https://codesearch.wmcloud.org/search/?q=wmerrors&i=nope&files=&excludeFiles=&repos=
[00:31:13] <TimStarling>	 it's possible I am misremembering and there is something useful in it we decided to keep
[00:31:45] <TimStarling>	 it was developed for PHP 5, and when we moved from HHVM to PHP 7 it seemed like there was no need for it anymore
[00:31:47] <legoktm>	 https://phabricator.wikimedia.org/T187147#4298721
[00:31:59] <legoktm>	 (linked from [[wmerrors]])
[00:33:40] <legoktm>	 I didn't look to see if anything related to that changed in PHP 8.0, just looked through the various type changes in the error callback
[00:35:01] <TimStarling>	 yes ok
[00:38:20] <TimStarling>	 it would be nice if this was just an upstream patch rather than an extension
[00:39:35] * Krinkle adds to wishlist for a php contractor
[00:40:29] <TimStarling>	 the reason I didn't consider a patch in PHP 5 was because of that comical alarm handler, but that was removed in the PHP 7 port
[00:41:36] <TimStarling>	 in PHP 5 it was very crashy
[00:44:10] <legoktm>	 having one less extension would be nice :)
[00:55:56] <TimStarling>	 answered on gerrit
[00:57:12] <TimStarling>	 s/_ex// and remove the last two parameters
[00:57:22] <legoktm>	 ty! I really thought I had searched through UPGRADING.INTERNALS but guess I missed it
[00:58:36] <legoktm>	 TimStarling: and that should be fine for all PHP versions right? not just 8.0+
[00:58:58] <TimStarling>	 yes
[01:03:24] <legoktm>	 updated
[01:14:33] <legoktm>	 thanks :) I'm going to try to add a test or two before doing a new release
[01:15:19] <TimStarling>	 speaking of PHP, Derick is asking me if I want to do a 45 minute podcast on the topic of ASCII case conversion
[01:16:32] <ori>	 ...that's pretty specific
[01:17:13] <TimStarling>	 ori: https://wiki.php.net/rfc/strtolower-ascii
[01:17:38] <ori>	 oh
[01:20:57] <legoktm>	 until that task+RfC I did not think the topic of ASCII case conversion could take up 45 minutes of a podcast
[01:24:08] <legoktm>	 it would be neat to listen to though :)
[03:33:55] <ori>	 it's still pretty specific
[03:35:30] <ori>	 TimStarling: I think you should do more podcasts, since the amount of lore and technical knowledge locked up in your head is vast, but this would be like.... 1,432,843rd on my list of topics I'd be interested to hear you talk about
[03:35:50] <ori>	 I guess it's up to the podcast host
[07:29:34] <_joe_>	 we do use wmerrors in production
[08:50:29] <TimStarling>	 yeah I figured that out eventually
[08:50:48] <TimStarling>	 I was the one who merged the PHP 7 support
[20:02:14] <zabe>	 Could 'LOCAL' be a valid wiki id?
[20:02:37] <zabe>	 if so, it was noted that https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/includes/user/ActorStoreFactory.php#128 could be a problem in a multiwiki setup with a so named wiki
[21:03:59] <Krinkle>	 zabe: I see no reason why it couldn't be indeed. That seems like an inproper way to handle logical distinctions. We tend to use structural solutions to that instead of reserved words. 
[21:04:35] <Krinkle>	 e.g. cacheKey = makeKey( foobar, local ) vs makeKey( foobar, by-wiki, $wiki )