[00:27:40] TimStarling: "asciibetically", from the guy who doesn't like "performant"? [00:31:29] well, at least it is precise [00:31:49] the main thing I don't like about "performant" is that it is vague [00:33:09] and it works very nicely as a sneer "he tried to sort it alphabetically be sorted it asciibetically by mistake" [00:33:40] it wouldn't be so poetic if I said binary order or by codepoint or something [00:33:57] s/be/but he/ [05:37:15] <_joe_> TimStarling: if you're still around (I guess it's about beer o'clock there) [05:37:58] <_joe_> I've seen a comment from you about DefaultSettings.php sections and how people don't respect them [05:38:22] <_joe_> I'd like to be a good MW citizen and respect those, but I'm not sure what the divisons are [05:41:09] <_joe_> uhm I think things related to ucfirst() behaviour should go into "Language, regional and character encoding settings [05:41:49] sounds about right [05:45:12] <_joe_> btw, first time I try to write a non-one-liner in core, the biggest challenge is finding how much of what you want to do is already implemented somewhere in the codebase. It's pretty large and diversified :) [05:45:28] <_joe_> oh and mw-vagrant, ofc [05:50:30] I don't use vagrant [05:53:02] <_joe_> you have your own local installation? [05:53:37] <_joe_> I was thinking of helping the people who're trying to make mediawiki-in-docker work well, out of frustration [05:57:02] ohai [06:29:57] I have my own special thing running under systemd-nspawn [06:31:06] I find it's easier to just configure apache than make some other thing configure apache on my behalf [06:31:40] bare metal performance, VM starts up in under a second [08:05:54] <_joe_> TimStarling: indeed, that's what I found attractive about docker [08:06:07] <_joe_> the advantage is you can respawn it whenever you want from scratch [08:06:24] <_joe_> and ofc at least on linux the performance is the same (more or less) as bare metal [13:57:48] Oh this is gonna be a fun in php 7.3 [13:57:49] https://www.php.net/manual/en/migration73.new-features.php#migration73.new-features.mbstring.case-mapping-folding [13:57:58] Where by "fun" I mean, another migration. [13:58:21] 'ßtrase' => "SStrase" [14:15:52] <_joe_> Krinkle: I think we're already doing that on php 7.2 [14:16:05] <_joe_> uh [14:16:09] <_joe_> apparently not [14:18:02] * apergos closes that tab in a hurry [14:18:30] <_joe_> Krinkle: well good thing we have https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/502546 [14:18:33] <_joe_> :P [14:18:53] <_joe_> but php 7.3 will be debian buster which also means [14:18:57] <_joe_> drumroll [14:19:04] <_joe_> a new ICU [14:36:08] You know, if we "just" had normalised page slugs, we wouldn't have this issue. (We'd probably have a bunch of other issues instead). But at least we'd have an entry in the DB for what a page's url is, and can match it, without 10 different systems being in charge of what the URL might be. [14:36:59] basically separating url ID from display title, anyway. One day, maybe. [15:07:37] _joe_: btw, do you have any idea why https://phabricator.wikimedia.org/T217846 no longer works? Or maybe it never worked on mwdebug? [15:08:47] <_joe_> Krinkle: I think it's a misconfiguration somewhere [15:08:54] <_joe_> in varnish I mean [15:09:17] <_joe_> or well, in the nginx between varnish and the debug servers [15:10:20] oh that thing. [15:10:27] right. [15:10:41] <_joe_> https://en.wikipedia.org/w/fatal-error.php [15:10:44] <_joe_> wat [15:10:50] <_joe_> Error:password not recognized [15:11:07] hehe [15:11:12] <_joe_> lol [15:11:24] <_joe_> this works under mwdebug as well [15:11:32] Yeah, you can have fun with Tim's easter egg there. [15:11:46] it's a real file. [15:12:17] but secured naturally to avoid abuse [15:12:30] <_joe_> right [15:12:48] <_joe_> it shouldn't be reachable from the public though [15:12:54] why not? [15:13:05] <_joe_> if it's exposed to abuse [15:13:15] It's just a dummy 200 OK response in its public form. [15:13:16] <_joe_> unless it serves some purpose in being exposed to the internets [15:14:02] it's useful to be able to debug not just on mwdebug, so it would have to be something other then X-W-D, which of course is also public. [15:15:00] it only fatals with the password and a specified kind of error you select from its delicious menu of fatals [15:15:09] <_joe_> oh yum [15:15:16] <_joe_> I'll have to read the code then [15:15:26] oops, sorry, bpirkle created that, not Tim! [15:15:34] (Thanks!) [17:30:44] <_joe_> Krinkle: re - opcache invalidation. If we revalidate files, we risk ending up with half-updated codebases for $revalidation_period seconds [17:30:58] <_joe_> because ofc the TTL is of the individual file, not of the whole opcache [17:32:50] <_joe_> we decided to disable revalidation because unless you have added a new entrypoint, it's basically static code. Well you could happen to have never loaded one specific include and to include it after it's changed, but right now we invalidate all of opcache when we perform scap sync{,-file} [18:42:53] James_F: I guess if that core test gets merged.. I should probably mail wikitech-l/mediawiki-l to give notification [18:58:27] Reedy: Is it likely to break things more than normal structure tests? [19:03:08] James_F: Not really... It's fairly obvious what needs adding [19:03:21] So shouldn't take people more than a few mins... Gated extensions should be ok [19:03:25] Yeah, maybe just leave it. [19:03:40] Yes, but we have 190 extensions in production and 30 extensions in gate. ;-( [19:04:18] I guess it's better than a flaky test in core just breaking random stuff [19:04:53] Flaky tests? In /our/ CI?! Never! ;-) [19:08:12] _joe_: yes, so the immediate approach would be 0 ttl, always revalidate, as php5 and hhvm and php7 all do by default. [19:19:08] and yes, mw is highly auto-loaded, which means it's unlikely/impossible for a single request to be able to warm it all up, so it will happen at different points in time. [19:20:06] I agree in theory that means as long as scap clear it each time it's fine, but that's not a theory I want to test as part of php 7 migration. We have a history of frankenstein and atomicity issues that I'd like to solve, and this sounds like a good part of that it could solve. But seems too risky too me to do at the same time. Do we need to? [19:42:22] Reedy: James_F: can we just statically analyze extensions and file bugs for them? check if there's a right- message and a corresponding action- one? [19:43:38] legoktm: Using an IDE? Plausibly, but I don't have that tool lying around. [19:43:43] Can do, if someone wants to write a script/similar [19:46:36] Based on gated extensions... I don't know how wide the problem actually is gonna be [19:48:12] <_joe_> Krinkle: always revalidate kills performance [19:48:14] <_joe_> badly [19:48:28] In our extensions... [19:48:35] 355 "right- in en.json files [19:48:48] <_joe_> it's really not a suggested setting even for small websites [19:48:50] 216 "action- in en.json [19:49:46] 40% missing? [19:49:53] Reedy: Is that deployed extensions? Ouch. [19:49:56] Nope [19:50:00] That's everything we host [19:50:06] Oh, OK, that's a bit better. [19:51:39] 38 extensions add rights [19:51:52] 28 have action- [19:52:21] Though, we fixed 5 [19:52:24] So only 5 more to do? [19:53:29] Also, my naieve grep doesn't do really nested stuff... [19:53:50] Starter for 10 I guess though [19:57:23] _joe_: isn't that what HHVM does though? I imagine it's just going into ram/disk cache for stat etc. [19:57:40] Or maybe it has some very small ttl hidden somewhere [19:59:25] Reedy: I'll have a list in a minute [19:59:39] forgot to git pull first... [19:59:42] heh [20:01:04] unified diff is bettererer [20:01:04] https://phabricator.wikimedia.org/T220779#5107992 [20:03:28] <_joe_> Krinkle: hhvm has the stat cache just for this [20:04:17] <_joe_> IIRC it uses inotify for knowing when a file changes, but I'll check on monday [20:04:29] <_joe_> still note this mechanism breaks sometimes [20:08:13] <_joe_> indeed, it uses inotify https://github.com/facebook/hhvm/blob/HHVM-3.18/hphp/runtime/base/stat-cache.cpp [20:08:41] Reedy: https://paste.fedoraproject.org/paste/Su0gESnxqOwqYs1kz4PRqQ/raw [20:12:24] inotify? hrrmm [20:12:30] not loving that [21:00:27] _joe_: right, okay, so without something like that in php 7 plain mtime checks on each request wouldn't scale even with a good os-level fs cache? That's unfortunate, but okay, amkes sense . [21:01:20] <_joe_> that's what we found out when we tried to run the API servers on hhvm without stat cache. Adding it halved the cpu usage (which was in good part due to system cpu time) [21:01:44] <_joe_> I was tempted to use a revalidation every 60 seconds [21:01:51] <_joe_> but I've read horror stories [21:02:15] _joe_: and the clearing of the opcache is all done and part of scap already? [21:04:11] cool, now I just need a place to document to run that shell command when hacking locally. [21:27:47] <_joe_> Krinkle: yes, that was a task I had to solve last quarter [21:28:55] legoktm: Your list missses FR which has weird nested i18n files :) [21:30:42] Probably some other oddities too [21:46:19] Reedy: Did you do a patch for AbuseFilter? It was in your diff but I see no commit. ;-) [21:46:55] James_F: Daimona did [21:47:09] I0dd31cb1cd5d34a2333a3b2341bc060f28c9162e [21:47:55] Aha, I was looking at your commits.