[00:28:49] tgr: how should I disable session handling? [00:28:52] in static.php [00:33:04] I don't see any memcached activity with tcpdump on mw1017 when I requested static/ resources [00:35:11] I do see WANCache:v:centralauth-user-[...] getting fetched multiple times per request, though [00:35:34] anomie: is that not subject to the same request-local caching that takes care of redis session lookups? [00:37:00] ori: CentralAuthUser loading is completely different code that I didn't touch. [01:53:32] anomie: sessions are created several times per request due to the PHP compatibility thing, and CentralAuthUser has no in-process cache, so couldn't that cause more memcache fetches? [01:55:17] that said, I doubt extra memcache lookups could be the direct reason for page save being twice as slow [01:55:35] a memcache lookup should be orders of magnitude faster than a DB write [01:56:12] ori: by defining MW_NO_SESSION before WebStart.php is loaded [01:57:13] session initialization should be mostly a noop if you don't have any cookies, but as far as I can see static.php would get the same cookies a normal page request does [02:04:23] bd808: what's the fawiki crosspost thing in the meeting notes about, exactly? [02:06:40] tgr: the link above that on meta. Haven't gotten a response on meta and the bot is mostly failing to log into fawiki [02:06:58] Err. Wikidata, not meta [02:20:26] bd808: so I can just copy the message there, right? [02:21:05] because we were talking about CLs but it doesn't look like there would be any need for that just to send him/her a warning [02:22:41] tgr: sure. [02:22:47] Only need help to translate if that was wanted/needed [05:04:21] mediawiki-config is still running php53lint? [07:08:51] ori: yeah, it's not under mediawiki/* so it didn't get batch updated. If you file a bug under #ci-config I can get to it in a bit [07:09:11] legoktm: cool, thanks! [08:31:00] ori: still around? [00:29:23] (PS1) Legoktm: Convert all array() syntax to [] [core] - https://gerrit.wikimedia.org/r/271208 [08:31:03] MaxSem: ^ [08:31:38] oh, I think it might be failing tests :/ [08:32:04] legoktm, https://gerrit.wikimedia.org/r/#/c/271208/1/thumb.php [08:32:18] whatdija use for conversion? [08:37:57] MaxSem: phpcs, but it crashed in the middle and I assumed everything was fine. [08:38:00] re-doing it now... [08:38:17] it was also in a vm, which probably didn't help [08:38:35] why vm? :P [08:38:59] so I could use hhvm, which is still way faster in a vm than php5.6 on my laptop [08:39:31] heh [08:47:06] legoktm, another thing: i would recommend against converting localisation files unless you want to edit-war with TWN [08:52:50] oh, yeah [08:52:53] good point [09:14:51] MaxSem: updated [09:17:42] HAHAHA legoktm [09:17:59] I think we found a phpcs upstream bug [09:18:27] / We use a blacklist approach as we prefer false [09:18:27] / positives to not identifying a pass-by-reference call at all. [14:32:24] legoktm: Do the CI tests complain about "array()" syntax now that you did the conversion? [14:32:54] or hashar, you might know ^ [14:33:35] anomie: if it is in phpcs yes [14:33:55] he might have bumped the style version [14:37:11] Looks like yes. Cool. [14:37:28] (at least, it happens when I run phpcs locally) [14:38:54] who maintains EventLogging these days? i have a couple patches to JsonSchema stuff waiting for a month now. [14:51:08] hashar: I wonder if it's worth me writing a structure test for bugs like T126799? (TL;DR: Someone didn't use Unicode NFC form for the "Module talk" namespace name in Urdu, so it wasn't possible to actually access the namespace on-wiki.) [14:51:08] T126799: Wrong Module talk namespace on Urdu Wiki - https://phabricator.wikimedia.org/T126799 [14:52:49] i wonder what happens if you make a namespace called "Talk:Talk" [14:53:08] I don't think namespace names can contain colons. [14:53:27] some sanity checks on them would probably be a smart thing to have. [15:24:52] 1672 files changed, 58093 insertions(+), 58043 deletions(-) [15:24:54] oh, ok then [16:35:01] anomie: from my mail spam, our code sniffer style v0.6.0 has a rule to disallow long array syntax release note https://gerrit.wikimedia.org/r/#/c/271218/2/HISTORY.md,cm [20:46:22] is there a way to know where a class that is loaded by composer was loaded from? (filename, directory, etc.)? [20:48:58] SMalyshev: new ReflectionClass('Foo')->getFileName(); [20:49:18] hmm... didn't think about that. Thanks ori! [23:33:26] TimStarling: the parser cache should vary on the value of $wgResponsiveImages (which controls whether HiDPI variants are emitted as srcset=.. attribute values on tags). How should I do that? Since this config is in core, the right way is to add a fragment to the key in ParserOptions::optionsHash, but that will cause the entire parser cache to be invalidated. [23:34:00] global configuration does not go in ParserOptions [23:34:28] well, it does, but it doesn't go in the options hash anyway [23:34:51] why do you think it should vary on that? [23:35:51] Mobile web should not get srcset=..., but mobile apps (which use the API to get html) should get it [23:36:48] it also seems a bit broken for someone to change that configuration option, reload a page, expect to see a difference, and find none [23:36:50] so you want a parser option which controls whether srcset is used [23:36:59] which by default is set to $wgResponsiveImages [23:37:06] and you want to vary on that parser option [23:37:47] so ParserOutput::recordOption() the first time Linker::processResponsiveImages is called? [23:39:16] well, ParserOptions::getResponsiveImages() or whatever will call ParserOptions::optionUsed(), which I guess is what you mean [23:39:55] as for wiping the whole parser cache... [23:40:40] the default value is true, so if I only add an option when $wgResponsiveImages is false, that will not wipe the cache [23:40:52] no, it will still wipe the cache I think [23:42:00] look at the key format in ParserOptions::optionsHash [23:42:17] // FIXME: Once the cache key is reorganized this argument [23:42:17] // can be dropped. It was used when the math extension was [23:42:17] // part of core. [23:42:17] $confstr = '*'; [23:42:22] there you go, you can use that one :) [23:42:52] set it to another value when $wgResponsiveImages is false? [23:43:55] mmm, maybe [23:44:20] there's an attempt at named options at the end of the list [23:46:02] you see how the printable option is done? it's a bit dodgy but there is that precedent [23:47:27] the only downside with that approach is that if some poor Wiki admin has $wgResponsiveImages set to false then their parser cache will be wiped when they update [23:50:25] yeah, that's OK I think [23:51:15] ok, I'll do that then. Thanks. Do you mind if I ping you for review when I've tested it? [23:51:23] when upgrading major versions, you typically bump $wgCacheEpoch anyways [23:51:37] sure, I can review it