[03:04:02] TIL: you can use git --no-index to to diff two random untracked files (and so you don't have to use wdiff which rather sucks in comparison to git diff --word-diff) [05:31:07] PHP sadness for the day: str_replace( [ '1', '2' ], [ '2', '3' ], '1' ) yields '3' [05:31:24] at least they have a big warning about it on the doc page [05:32:25] (yeah, yeah, I should have used strtr) [05:49:48] <_joe_> tgr: oh my [16:27:29] <_joe_> Krinkle: is there anything you need me to work on for collecting profiling/sampling from PHP7? [16:27:40] <_joe_> I have no idea what the status there is, but I guess you probably know [16:28:12] _joe_: last I know, Tim and you installed tideways on at least mwdebug and fixed up wmf-config, and then I tested it with XHGui, and it didn't work yet. [16:28:33] haven't had a chance to debug the debugger yet. [16:28:44] https://phabricator.wikimedia.org/T206152#4910233 [16:28:47] <_joe_> I was also interested in understanding how we plan to collect data from excimer [16:29:27] _joe_: The plan is to do it the same way as for xenon. Shutdown function that flushes to redis (different topic, same instance). [16:29:27] <_joe_> ok, tomorrow I'll try to dig a bit into why xdebug doesn't work [16:29:36] <_joe_> probably it's lacking some config? [16:29:36] s/xdebug/tideways/ [16:30:06] this is for XWD profiling to xhgui. [16:30:15] <_joe_> aren't they the same thing just different versions? [16:30:29] xdebug is some php extension I'd never use. [16:30:41] tideways is loosely related to xhprof. [16:30:46] xdebug isn't related. [16:31:15] James_F: have we considered making a Wikimedia* extension for storing the namespaces / log i18n from undeployed extensions? [16:31:15] xdebug is what changes var_dump() in PHP on Apache to print nice HTML reports and such. [16:31:26] we don't use it in prod. [16:31:55] tgr: Or just dumping them into WikimediaMessages. [16:32:13] xdebug used to add a lot of memory corruption safety checks too. Not sure if it still does in php7+ [16:33:55] <_joe_> Krinkle: right, sigh it was horrible [16:33:59] xdebug is nice for local development [16:34:03] <_joe_> xdebug I mean [16:34:07] <_joe_> I hated it [16:34:18] on a server, it basically functions as a backdoor for arbitrary remote code execution [16:34:19] <_joe_> and yes I was thinking of xhprof ofc [16:34:48] yeah, that's a feature for IDEs as well. [16:35:16] I've never used it that way, but in theory it would allow you to debug PHP as nicely as we can JS in browsers. Step by step execution and scope evaluation. [16:35:27] it's super nice [16:35:30] but yeah, local-only, definitely. [16:35:43] just not something I'd want to anywhere near real data [16:35:46] I prefer offline neural debugging [16:36:04] with a few var_dumps to fill in the blanks. [16:36:53] ad.dshore added support for the IDE port in mediawiki-docker-dev, I'll have to check it out one day. [16:37:09] tgr: which IDE do you use/prefer for that? [16:38:17] I use PHPStorm which is a bit painful to configure for PHP debugging (with Vagrant at least) but once you did set it up it works very nicely [16:41:13] https://www.mediawiki.org/wiki/Manual:How_to_debug/with_MediaWiki-Vagrant_and_PHPStorm [19:13:43] duesen, I had a question for you about routing when you have a second [19:16:39] istm the PathRouter module does most of what we need to do for routing positional arguments (like "/page/Abraham_Lincoln/revisions") to the right handlers for REST, and it even has a hook [19:17:05] It was something we were discussing at all-hands, that we'd have to build it, but it seems like it's already there [19:25:33] eprodromou: Looks like it's mainly for parsing the positional arguments, it doesn't actually do any routing as far as I can tell. I don't see any hook in it. There is a hook the one place it's used in WebRequest, although as far as I can tell that use is mainly intended for the index.php entry point. [19:27:03] anomie: that was the hook I was thinking of [19:28:08] But you are entirely correct! It parses but does not route AFAICT [19:28:23] In PHPVersionCheck, what does upstreamSupported actually mean? PHP currently do 'support' for PHP 7.2.x and security support for PHP 7.1.x. Which do we mean? [19:30:36] James_F: Looks like it's only used for displaying the message "Please consider upgrading your copy of PHP. PHP versions less than $upstreamSupported are no longer supported by the PHP Group and will not receive security or bugfix updates." [19:31:12] Yeah, but those numbers are different for PHP. :-) [19:31:41] I guess I could add a different upstreamSecuritySupported variable and add a different, more strident message… [19:33:47] It looks like the code there also assumes that 'minSupported' will always be older than 'upstreamSupported', because it says that unconditionally when 'minSupported' is not met without actually checking against 'upstreamSupported'. [19:34:19] Yeah, which isn't great. [19:34:22] Patch forthcoming. [19:35:24] I wonder why we even have 'upstreamSupported' and that message in there. It's just going to quickly become out of date. [19:37:50] It's nice to remind users about security/bug issues that aren't necessarily going to break MW but should be fixed? [19:38:33] Also, how much are we really trying to support PHP < 4.1.0? Checking for the version_compare method seems a bit extreme. [19:41:43] Really old code, apparently. It looks like the origin of the warning in its semi-modern form was r85918, and probably evolved from the "PHP4 is old" warning added in r41713. [20:14:57] * James_F nods. [20:15:26] OK, I've put up https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/490685 but at the least we can't merge it before Wikimedia production is running code that won't flood the debug channel. ;-) [20:26:55] <_joe_> if we're building a router for urls, can we maybe tackle https://phabricator.wikimedia.org/T104755 :P [20:31:16] * anomie points to https://phabricator.wikimedia.org/T104755#1744084 :P